5
\$\begingroup\$

I writing this as I have run into a dilemma that I cannot readily answer.

Specifically, how many threads is too many?

Background tl;dr:

  • Writing a game (Surprise.)
  • C++11, all server-side bits running on Linux server installs (headless)
  • Login server and chat server are on a single server
  • Database server/processing is its own server (eventually)
  • The world server is the 'master' server, in which zone 'servers' (threads) are spun up. Each zone 'server' is responsible for a specific planet and all that entails (npcs, entity lists, etc).

With that brief intro, is there a point in which there are too many threads? Assuming there are 10 planets (zone "servers"), each with their own thread, would there be any extreme problems (not performance bottlenecks) that need to be accounted for in this type of situation utilizing an 8 core server? Would the same problem persist at 16 cores?

The end goal would be to allow for up to three "instances" of each planet, with maybe 20 planets (~60 threads) in the end. I understand that this could cause CPU contention as each thread is waiting for CPU cycles, but not enough to effectively hang the system (excluding a zone server locking up). If the game progresses to that point, 32 core servers would be an (expensive) option.

Is there anything that I am missing or not understanding?

Thank you in advance!

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ I think that all makes sense and is fine, but I worry that maybe your game idea is too big. \$\endgroup\$
    – Draco18s no longer trusts SE
    Apr 27, 2017 at 21:59
  • 1
    \$\begingroup\$ On my machine, I have about 150 proccesses, with more than 1600 threads, and less than 3% CPU utilization, and I only have 2 cores. It is not the number of threads you have, but how much CPU time they take. \$\endgroup\$
    – Theraot
    Apr 27, 2017 at 22:25

1 Answer 1

Reset to default
7
\$\begingroup\$

What matters is not the number of threads, but their CPU time

Probably you do not need your threads to have full utilization. If you do, get better hardware. In fact, you can use CPU utilization as an ad hoc metric to decide when to improve your hardware.

Let us say that your server threads have to complete a tick each 50ms, yet, your CPU is fast enough that it can do the required computations in only 20ms. Now, you can afford to have a core switch between two instances, because each needs less than 50% utilization. You may want your threads to yield or sleep to archive this.

On the other hand, chances are you may have to compute things that do not fit in your tick. In addition, you may want to do those asynchronously, perhaps taking threads from a thread pool.

Know how to scale your server

Before you buy hardware for a public release, it might be good idea to do the following:

  • Identify what are the performance variables (number of players, number of objects, size of the maps, etc…)
  • Know your performance and requirements scale respect to those variables. You will know this from analysis of your algorithms.
  • Estimate projections of those values for your public release (how many players will you support, etc…)
  • Most importantly: measure the performance of your server (on the hardware you have, for known parameters). In such way, you can calculate how it will behave on a CPU X times faster with Y times more players, and so on…

This should give you enough information to know what hardware you need to start with, and some idea of how it will scale.

Improve this answer
\$\endgroup\$
1
  • 1
    \$\begingroup\$ I think this is all good advice all in all, but misses an important point: If you can separate your zones logic one from other (or keep integration by messages and by a minimum) you should be able to instead of spawn threads, spawn services. And then you can scale horizontally into multiple machines. \$\endgroup\$
    – Gustavo Maciel
    May 3, 2017 at 14:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .