Memory leak

[jgaskins]

After @jwoertink posted jgaskins/redis#33 I did some investigating and managed to narrow it down to Cable, replicable on the master branch. The code I used is here (diff).

Reproduction:

1. crystal run examples/app.cr
2. Vist http://localhost:3000
3. Press and hold Cmd-R/Ctrl-R for a minute or two to simulate thousands of page views
   • Keep an eye on Activity Monitor or htop during this and watch it go up
   • curl or wrk won't do the trick (AFAIK) because the repro requires WebSockets, so these need to be actual page loads
4. Leave the server running (even at idle) for an hour or so and when you come back it will be using even more memory

[jwoertink]

Nice find! Looks like it's time to go digging around in here.

/cc. @fernandes

[jwoertink]

Not 100% sure, but I think I found it here c2e500b

It turns out that the hash just kept growing and growing. Though, I'd imagine Crystal would be pretty efficient on super large Hashes, it's the only thing I found that was sticking around longer than it needed to.

[jgaskins]

@jwoertink Nice find! I tried my branch that I used to discover it and sure enough, it was leaking hashes there. But that wasn't the only leak there was. I still saw memory growth with each WebSocket connection made.

I managed to trace it even deeper and what I found wasn't even in the WebSocket handler code — it was, surprisingly, in the WebSocketPinger. With #51, memory usage stayed at right around 19MB on my machine no matter how long I hammered that refresh button. I put it in a single commit so you can cherry-pick/merge into your branch for #46.

[fernandes]

uow, these changes are really great! thanks @jgaskins for jumping into it..

#51 is great fixing the websocket pinger, and c2e500b helps with the hashes.

Merging 51 and cherry picking the commit above into master would make it really strong (specially given @jgaskins comments on the tests performed)

TL;DR let's merge the PR and cheery pick c2e500b ? 😎