Which do you think is the best number of threads to allocate for websocket connections to a 10-player world, given that each connection requires a separate thread, and why?
#
Why
A.
150
Assume a maximum of 100 players + 50%
B.
80
Assume a maximum of 80 players
C.
12
One connection per possible player + 20%
D.
10
One connection per possible player
E.
0
The whole problem is that players keep connecting
F.
None of the above, you think it should be something else
G.
None of the above, you’d really prefer I not touch it, but that accidentally turns out to be the same as one of the above
H.
You think this should have been a poll so you’re not voting in protest
If there are cases where more computing is needed than just what the thread held by the socket does, then at least 1.2 threads/player.
If there are a bunch of other things happening in addition to negotiating communication, and the connection thread is dedicated to the connection negotiation, I’d guess having either a higher thread/player ratio like 1.5 might be better, or even just a flat 1.2/player plus ten for world doing world things.
Hard to evaluate without more info on how the server handles things, though.
P.S. At first, I wondered why it wasn’t a poll, but then I saw that you wanted the why, and now I think this is best.
Is it possible just for context that we know how many threads are currently assigned to each connection?
C looks like the obviously best option, but I worry that there may be instances where you may need double than that.
Or you know, even more than that. Like, does the world actually do it’s world things when there’s no players on the planet? If no, does it do it all on the player’s threads? If yes, the answer becomes a lot more complicated.
Since the max number of players would be 10 and there is no way to raise that number client side (unless you are adding options to the 9.99 plan), I would say D. If that is already the case and is causing an issues, then C.
Oh, good points! I’m only thinking of the worker threads allocated by (and older version of) CivetWeb, documented here. The only difference is Boundless uses CivetWeb for persistent websocket connections. These threads don’t do any Boundless-specific work, they only send and receive bytes I believe.
If each WebSocket connection requires a separate thread (i.e., you’re not using an asynchronous or event-driven model like Node.js or Python’s asyncio), and you’re supporting 10 players, then the best number of threads to allocate is 10 — one per active connection.
Here’s why:
Thread-per-connection model: In this model, each WebSocket connection blocks a thread, so allocating one thread per player ensures that all 10 players can maintain a live connection without waiting for a thread to become available.
Responsiveness: Allocating fewer than 10 threads would force some connections to queue or drop, creating lag or disconnections. More than 10 threads won’t help unless you’re preparing for more players or handling other tasks.
Efficiency: Allocating exactly 10 avoids wasting system resources on idle threads while still covering all players.
Additional Considerations:
CPU Cores: If your server has fewer than 10 cores (including hyperthreads), you might start to see some performance degradation due to context switching, but for only 10 threads, most modern systems handle this easily.
Other Tasks: If your server does more (like AI, physics, or DB I/O), you might want to allocate additional threads for those tasks, separate from the WebSocket threads.
TL;DR:
10 threads — one per player — is optimal if each WebSocket connection strictly requires its own thread. If you’re using an asynchronous model or thread pooling, the number could be lower.
That’s my guess too. If so, I’m wondering if it’s reasonable to cap the number of extra portal “spectators” to 20% of max players. E.g., 12 connections max for 10 players, 48 connections max for 40 players.
I think it’s just cap + 1 observer, but I’m not sure. Can you set a world in your test space to have a player cap of 1 and see what happens if 5 clients try to look through portals at it?
Just a side note to think about just because a planet has a said player limit does not mean it wasn’t set for a buffer. I run a hunt on a medium planet (20 players) but we have on occasion had a few extras. in one case 24. once the players dropped back down to 20 as people left during the hunt it then maxed it at 20. But when people were arriving it let us initially surpass that number. That’s why I think they built it with a small buffer probably like your C option.
Good point! It’s actually quite easy to change. It doesn’t take much more than stopping the worlds and starting them again with the updated code.
Funny enough, it looks like one of the main reasons that stopping and starting all the worlds takes as long as it does is because of the number of threads that have to get cleaned up and then recreated each time. Currently each world creates 150 threads for websocket connections and 232 threads for http connections. The total number of threads waiting for a connection across the whole universe is close to 100,000.
All that aside, I’m not computer/code literate enough to understand all that, but I would think option C would be best. The 10, plus a little wiggle room.
