I’m interested in determining the maximum number of game sessions that can be hosted on a single server instance. Currently, a major challenge is simulating network connections to evaluate the performance of my game’s headless server. For bandwidth, I can estimate it by multiplying the consumption from a single connection by the number of players. However, gauging CPU and memory usage is more complex.
My question is: Is there an efficient method to estimate or simulate CPU and memory usage for a given number of players without establishing real connections?
I’m curious about Thin Clients, but this feature lack of documentation makes it difficult to know if its suitability for my needs.
Edit:
Also, it would be amazing if you provide any other advice regarding Headless Servers.
Thin clients are the way to perform load testing and for benchmarking the server with clients that actually connect.
The server will see them as normal clients, so data will be sent to them and processing of the entities will be carried as normal.
Thin clients, from their end, have no presentation, nor process any ghost data. End results: they only send input to the server (random, because they lack context to do anything better, apart recording the input itself) and they can read and handle rpc.
So a way to do that would be to make a server build, and use the editor to spawn thin-clients (or use a build where you just create thin clients) and let them connect to the server.
However, a real connection is still made. I would say that connection is still part of the CPU cost and should be considered. There is a cost due to the processing of many connections that while not big, it is still large enough.
Not to speak, having a connection is necessary to make the server send data (that is usually one of the the largest cost).
In case you need to make a build with multiple thin-clients (but no client) you can write your custom bootstrap for that and hang a build that spawn up to N thin per process, making affectingly this test pretty fast. The annoying bit: you still need to make build. However, and that the point, because of the missing visual and the fact there is little processing, for that one specifically you can:
remove all shader compilation
avoid using burst (because probably not necessary)
From you bootstrap method call the CreateThinClientWorld from ClientServerBootstrap.
Then connect the thin client to your server.
Repeat the operation has many time as you want Thin Clients.
Then make a system that has the [WorldSystemFilter(WorldSystemFilterFlags.ThinClientSimulation)] attribute and in that system set you input component for the thin client.
Not to hijack the form, Would someone be able to give a quick rundown of what they were able to achieve?. I just like to know if ECS net code is better than another framework, let’s say like mirror.
, Before committing to a full day of testing of the netcode that code.
And what I would be seeing in comparison.
We publicly state 100+ players comfortably (see https://create.unity.com/megacity-metro), but our teams expectation is higher (depending on use-case and hardware). The problem is that, at these kinds of scales, it quickly becomes optimization-specific, and thus game-specific, which is why we haven’t currently released any CCU benchmarks.
One gotcha with Netcode for Entities is that we default our Netcode settings to an aggressive, bandwidth & CPU-intensive strategy (1 snapshot per player per tick @ 60Hz, ~1400 bytes each, and every ghost is considered important enough to be added every frame). It is necessary to tweak these settings for a game attempting to reach 100+ player CCUs. See the optimizations doc page for details of where & how you can make significant improvements without impacting gameplay quality.
Hey!
You can create ThinClients with CreateThinClientWorld. That works for me so far, but how can I connect this ThinClient directly to a server with a specific IP and port? So far I have only found this through the PlayMode Tools window, but is it also possible through code? And if so, is it also possible outside the editor?
In the same way you would for full clients. NetworkStreamDriver singleton, Connect method. My suggestion would be to have all thin clients “follow” the main client. I.e. If the main client uses a relay code, the thin clients can join via the same NetworkEndpoint struct.