3 ms·
Now that you can buy servers in tiny linear increments, it seems more interesting (but less headline-y) to talk about KB per connection or CPU per connection.
by nulltype 11y ago
Now that you can buy servers in tiny linear increments, it seems more interesting (but less headline-y) to talk about KB per connection or CPU per connection. It looks like this is about 41KB per connection.
For comparison, I checked my not-very-optimized go server, and it looks like (based on VSZ value) to use 25KB per connection in go, with 43KB per connection used by nginx (to provide SSL termination).
- chrismccord 11y agoLike I highlighted elsewhere, did your Go server setup a separate multiplexed process for the PubSub channel and track the PubSub subscribers on each client connection? Comparing the client size to raw WS connections isn't accurate in this context. Horizontal scaling is nice, but you also have to consider the overhead in broadcasts that now are distributed over dozens/hundreds of nodes vs a handful of large nodes.
- nulltype 11y agoI track the pubsub subscribers on each client connection, but I'm not sure what you mean by a multiplexed process for the pubsub channel. Depending on your traffic patterns, considering the broadcast activity is potentially important, and then you might worry more about CPU than RAM. I use redis myself, but gnatsd or redis cluster may help with scaling the pubsub part of the system.