So basically cell won't be eaten/exploded by virus until server says so? I would have thought that would be perceived as too slow.
Per server you mean like in a game room or is one game room equal to one linux box? If so, I guess then that handling the game logic was the bottleneck, not the number of concurrent connections?
Also, congrats on the success and making some really cool games.
Per game room (each room is a process). I end up just using boxes that have 1 CPU core and run just that game room in there. Except for some dedicated servers that have 40+ cores, in which we run 40+ processes.
On Agar.io doing all the collision checking and encoding the packets is the biggest bottleneck. Similarly for Diep.io. Number of players of course increases those two factors almost linearly. For example, Diep.io doesn't process shapes that aren't being transmitted to anyone.
At first I tried checking every creature for collisions against everything else, but unsurprisingly that was too slow (N^2). To reduce the checks I put each creature in a grid cell based on their position, then check for collisions only against creatures in the same or adjacent cells.
I think overlapping grids would be even more efficient, or perhaps to do these checks on GPU.
It's a custom written WebSocket implementation, see https://news.ycombinator.com/item?id=13267261
I think Agar.io has around 190 players per server. Diep.io has around 72.