It appears that our game, even though we have spent tons of effort into parallelizing our systems and workloads to make use of actors as “workers” below, is only getting a single cpu core allocated to it:
This is a game that has a maximum player count of 6, which seems to be creating a hard cap on if the server can get more cores allocated to it or not. Note that this is also a best case scenario, the same worker tasks sometimes add up to 20ms or more.
A different game of ours with a 30 player lobby, that does not need any parallelization at all, for some unknown reason gets 3 or 4 cores allocated to it. This is even though the only parallelizable task is native physics and replication. The total server frametime for that game is less than 2 milliseconds with parallelization, and would have been maybe 3 milliseconds without, which does not seem to necessitate the amount of cores it gets:
I expect servers that have parellelized workloads to get more than a single cpu core allocated to them, especially if they explicitly opt in to parallelization in their scripts, using actors. CPU scaling being affected mostly by the number of players per server does not lead to accurate results.
I have this same problem. Additionally, I would like it if there was a way to set the number of cores, so that I know from the start how much performance headroom I have. My issue is that because my server processes are so expensive, if I were to make use of multiple cores, I would essentially have redesigned the entire system to rely on that extra core existing to keep server functions running properly. With no guarantees on how many cores I get, all I can do is cross my fingers and hope my heavy server usage gets logged and the mystical Roblox black box decides I’m worthy of an extra core.
Hi @filiptibell ,
Right now we limit number of cores and threads being used by an experience based on its maximum player count. A game with maximum 6 players get one core and one thread. One with 30 gets 3 cores and 3 threads.
Here one core means the compute resource equivalent to 1 core. It could be 100% of the CPU time of a single core or 50% of the CPU time of 2 cores, etc. It’s up to the operating system to allocate resources between multiple server instances. However, usually all cores are being used, for a game with one core, it is more likely all its work will be run on a single core.
For a game running with one core, there is really no benefit to having it running on 2 threads, since there is a cost to switch the thread running on 1 core. It will also perform worse when running 2 threads on 2 cores using 50% the CPU time of each core, since there is likely to be more cache misses and there are cost to multi-thread.
With what is said above, we believe the current strategy for core and thread limitation is optimal.
It is a good practice to parallelizing workloads. I think 2 or 3 workers for a game like yours are perfect. When your game starts to scale at some point, you will see the benefits. And as I mentioned above, there are still chances to parallel workloads in the 30-player game. It’s just up to the server OS to decide how much threads will be running at the same time.
As for the 6-player game, if its server frame rate is better than 30, it should be good enough.
Hi @fishrotR , thanks for your reply and more in depth information than the creator hub currently provides.
It is a good practice to parallelizing workloads. I think 2 or 3 workers for a game like yours are perfect.
The game with several workers and a parallelizable workload is the one with 6 players per server and is currently not benefiting from that parallelization at all.
When your game starts to scale at some point, you will see the benefits.
What does this mean exactly? We will not scale our game beyond 6-player servers because of memory constraints. Even with streaming enabled and optimal settings for memory usage scaling beyond 6 player servers would raise crash rates on older devices. We would also have to remake the entire map to accomodate more players since it is composed of voxel terrain and distinct player bases. Targeting a player count of 6 was very much intentional.
And as I mentioned above, there are still chances to parallel workloads in the 30-player game. It’s just up to the server OS to decide how much threads will be running at the same time.
That game is a completely static map serving as a lobby and would complete its full frame within max 4ms even without parallelization, it is not really useful there.
As for the 6-player game, if its server frame rate is better than 30, it should be good enough.
I disagree, that 6-player game is a shooting game and having an update rate that is too slow can lead to misses in shot validation.
I understand that the philosophy behind resource allocation like this is that it is based on player counts, more or less like serverless architecture in the web world scales with page visitor count. However, limiting available cpu resources here on Roblox based solely on player counts does not lead to accurate results, as demonstrated above.
For one thing, if this behavior cannot be changed, please at least document the specifics of core allocation on the devhub. If we could know exactly how many cores get assigned per player cap, it would be massively helpful.
Also, to clarify what you were saying, is the core count assigned based on player cap? Or the number of current players in a server? As in, if I have a 100 player server with only 1 player in it, will I get the number of threads that corresponds to the 100 player server, or will I get only one thread, scaling up as more players join the server?
My game operates in 12 player servers and because of my server authoritative physics system, the server is pretty much fully maxing out its one allocated thread (I run my processes off of Heartbeat, and the server currently takes about ~14 ms per frame). I was really hoping that parallel Luau would allow me to increase my potential server performance; as is, regardless of whether you parallelize your workload or not, if you don’t get that extra core assigned, there are no gains to be had.
With many developers focusing on making more complex games, such as server authoritative physics, the need for higher server performance is there. This is not a matter of optimization, my code is already written as efficiently as possible and utilizes various algorithms to speed things up. I appreciate the helpful answers, but I have to admit, the current stance towards awarding more server threads to games is severely disappointing…
I’ve done some testing on this, and here’s what I found:
Core count is indeed dependent (only?) on max server size, not number of players. Here’s how it scales:
1-19 players: 1 core.
20+ players: 2 cores.
30+ players: 3 cores (I tested at 50 players and got only 3 cores, I haven’t tested player counts between 50 and 100 but it can be assumed at some point it goes to 4 cores).
100 players: 5 cores.
700 players: 9 cores. (maximum number of cores).
As anticipated, Roblox will only give you more cores if you are saturating the existing cores. I don’t know what percent of CPU time you need to use up to receive an additional core. From my testing, it seems that the number of cores available to you each frame depends on this logic, so one frame you might get 2 cores and the next you might get 3 (depending on how taxing your work is each frame).
I was wondering if there are plans to automatically detect whether a game needs more threads or not or for some type of dynamic threads which get used when the task is too much.
My game is a heavy physics type of game which could greatly benefit from this.
I rewrote my entire server side to work with 16 threads as i remember from RDC each server has 16 threads which dont do anything due to this not being utulized in parallel.
Now i came to the conclusion only 1 core is assigned per server after having gone through all of this trouble to make the server work with 16 threads and wanting to see how many cores the server actually has just for fun.
I need atleast 4 threads to get a massive benefit from parallel lua and prevent my servers from freezing.
My game has a maximum of 10 players because the server cant handle any more without causing too many massive freezes and 30 players would be too hectic to have in my game.
I planned to increase the playercount to 18 players thanks to this feature but now it seems impossible to me as there will never be enough threads to prevent server freezes.
I hope something could be done to allow more threads to be used in the future for my game.
Hello! At the very least, this sort of limit should be very accurately documented or made queryable for creators so that time is not wasted parallelizing games below the invisible thresholds Roblox has set. This is not currently documented whatsoever to my knowledge.
