Slow connection to rooms

[NikolaiSmartfoxx]

I created a stress test in which 1000 users entered the same room at the same time, it took 80 seconds, although one user in a normal game connects in ~9 milliseconds.

Judging by the logs, the ISFSApi.joinRoom function takes up most of the time and what is the strangest thing is that the time in the stress test varies from 9 milliseconds to 2 seconds. I think it's about the priorities of the stream. A snapshot of the server settings is attached.

Is it possible to optimize this, or is it a matter of machine power?

[Lapo]

Hi,
it depends on the conditions of the test.
Are server and clients on the same machines or separate?
What are the hardware specs of the server?
Did you check what is the CPU usage during the test?

Also when you're saying that 1000 clients are connecting "at the same time" I hope you did stagger them by a few milliseconds (20-30 at least), otherwise you're creating a pretty unrealistic stress test.

Cheers

[NikolaiSmartfoxx]

Hi
The server is running ec2 under network loadbalancer(opened for TCP and UDP), the client is on my local computer.
server machine - 16.0 GiB, 4 vCPUs, network — Up to 5 Gigabit
The processor is 100% loaded, and the admin panel dies during the test (the result is updated every 10 seconds)
It's almost at the same time, I'm creating 1000 threads on my local machine (32-core processor) and doing connect and join_room for all users(So there is a delay of several ms)
Request are sending by TCP, also I tried to use UDP, but test show the same result.

[Lapo]

If CPU is 100% loaded you're pushing the hardware to its limits, which explains the latency.
However I would expect that a 1000 CCU doing a connection + login + join Room would pose very little problem for a 4-core machine, even in the cloud.

In fact we have run dozens of tests on AWS tiny servers, such as t3.nano and t3.micro (which have less cores and much less RAM) and have reached 2500 CCU on the smallest instance with no problem.

Make sure to leave a minimum of "breathing room" between each client connection, such as 20millis which is still very reasonable value for a stress test. If you're firing all connections+login+join at almost the same time it may cause larger CPU spikes on low-end hardware.

Cheers

[Lapo]

Side question: why do you need to create a 1000 threads on the client side?
If you're using the SFS client API they already create the necessary threads internally. All you need to do is running a for loop that generates every client and starts the connection, followed by a brief Thread.sleep() invocation to stagger the clients by a few millis (such as 20-30)

Cheers

[NikolaiSmartfoxx]

Regarding to loop connection(), I am trying to simulate 1000 connections at the same time and use threads to make calls in parallel(1000 users trying to login simultaneously, not one by one in queue). the goal is not to keep a lot of CCU, but to see how the server will cope with the huge influx. I see in the admin panel that the CCU increases to 1000 almost immediately, but when users start joining the room, the server dies.

Here code examples:

create thread:

ExecutorService executor = Executors.newFixedThreadPool(threads);
for (int i = 0; i < threads; i++) {
SFS2XStressTestTool task = new SFS2XStressTestTool();
executor.submit(task); }



SFS2XStressTestTool implements Runnable:

@Override
public void run() {
this.conn();
}

public void conn() {
sfs.connect(cfg);
}

private void onConnection(BaseEvent evt) { // SFSEvent.CONNECTION
inData.putText("device_id", UUID.randomUUID().toString());
sfs.send(new LoginRequest("", "", null, inData));
}

private void onLogin(BaseEvent evt) { //SFSEvent.LOGIN
sfs.initUdp("game.com", 9933);
}

private void onConnectionUDP(BaseEvent evt) { //SFSEvent.UDP_INIT
r = new ExtensionRequest("JOIN_ROOM", SFSObject.newInstance(), null, true);
sfs.send(r);
}

[Lapo]

The discussion about threads is not very relevant to your issue but I brought it up just to clarify that each instance of the client API (used for the stress test) already creates the required threads for connection internally.
This means that using an external thread pool is redundant. If you want to learn more about building a stress test tool take a look at this article --> https://smartfoxserver.com/blog/buildin ... test-tool/

Back to your specific issue, if you want the server to be able to sustain a massive influx of client requests literally at the same time you will likely need a more powerful server.
Just keep in mind that the scenario you're testing is unlikely to happen in reality. What is more likely to happen is that just a few users will connect/login exactly at the same time, meaning within the same millisecond.
Even a moderately large spike of traffic will have requests staggered by several millis which is enough to avoid overloading the server, usually.

The scenario you have in mind is one where you have hundreds of thousands of CCU, where it is more likely that connections will happen very close to one another. If that kind of traffic is the expectation then of course a tiny 4 core machine is not going to be enough in the first place.

Cheers