There are two changes here, only one of which really makes a difference (I think). First, I am explicitly calling close() on channels before they go out of scope, because I'm not 100% certain that when we delete the containing map entry we don't still have a reference to it somewhere else, which causes a memory leak. (Either way, closing the channel can't hurt.)
The second change is probably the more useful one: taking the user table channel buffer length down from 16,384 to 1,000. I think when the code was written it was assumed that this allocated 16k bytes for the channel, but it actually allocates enough memory to store 16k strings. Assuming the size of a string pointer in Go is (64-bit length + 64-bit pointer) 128 bits, using 16k for the buffer length means that Freddie requires 256KiB of memory per connection. Dropping down to 1,000 puts it at 16KB per connection.
At any rate, these two changes mean that our Freddie instance goes from OOM-ing after trying to allocate >32GiB of memory to using ~8.5GiB to service 128k concurrent connections, so it's good enough for now.
There are two changes here, only one of which really makes a difference (I think). First, I am explicitly calling
close()on channels before they go out of scope, because I'm not 100% certain that when we delete the containing map entry we don't still have a reference to it somewhere else, which causes a memory leak. (Either way, closing the channel can't hurt.)The second change is probably the more useful one: taking the user table channel buffer length down from 16,384 to 1,000. I think when the code was written it was assumed that this allocated 16k bytes for the channel, but it actually allocates enough memory to store 16k strings. Assuming the size of a string pointer in Go is (64-bit length + 64-bit pointer) 128 bits, using 16k for the buffer length means that Freddie requires 256KiB of memory per connection. Dropping down to 1,000 puts it at 16KB per connection.
At any rate, these two changes mean that our Freddie instance goes from OOM-ing after trying to allocate >32GiB of memory to using ~8.5GiB to service 128k concurrent connections, so it's good enough for now.