[not an issue] performance measurements

[inlife]

Hello,

First of all, very nice project, keep it up!
And second, I have a few questions:

1. Did you conduct any performance measurements for goworld server?
2. How many simultaneous client connections it can handle (with one, and multiple gates)?
3. Does goworld support a 60HZ or 30HZ sync modes, and how many entities it can handle with such rate, (probably disabled encryption/compression) ?
4. What are the theoretical limitations for the entity amount ?

And more general question, do you have some sort of text description about your network culling algorithm? As far as I understood you call it Area of Interest.

Thank you! 👍

[xiaonanln]

VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6082104 2.947g 8980 S 1037 3.1 18:54.20 test_client
3365296 1.237g 8156 S 300.9 1.3 5:46.70 gate
3202544 1.160g 7628 S 282.0 1.2 5:30.26 gate
10.059g 9.986g 2452 R 100.0 10.6 0:08.83 redis-server
4162304 2.347g 9204 S 19.9 2.5 0:33.17 test_game
1137360 59168 7444 S 7.0 0.1 0:08.13 dispatcher

I did a simple test using examples/test_game as the server and examples/test_client as the client.
The test_client opens 4000 connections to server, with KCP+compression+encryption enabled. test_client simulates variaous player operations. test_client also synchronizes player position to server every 100ms.
The test showed that each gate can handle about 2000 clients. If more than 2000 clients are connected to the same gate, the client side will experience increased network delay.

CPU of test_game is 19.9% which is related to game logic.
CPU of dispatcher is only 7% for 4000 players, so it is far from its up limit. Note that dispatcher can exploit multiple cpu cores so 100% CPU is not the up limit.
GoWorld can handle more clients simply by adding more gates and games. The current implementation supports only 1 dispatcher, and dispatcher shard will be supported in the future.

[inlife]

thank you for the information! 👍