I am recently working on a server for a game (1 vs 1 with observers) that shall support parallel games and I wonder whether it is more efficient to
- create 1 extra thread per game/lobby or to
- let one Thread handle all the Input (the tcp-output will be a separate thread anyway)
The recent structure in brief (supporting only one game), the server receives and queues up all input, the logic-thread takes the queue's head and handles it, all output is queued up and handled by another thread. At this time we already got 3 threads running (one is the server itself). Threads are handled by
ExecutorService. I wonder if it makes sense to fork in the logic-thread when I assume that the machine the game will run on later might have 2 cpu cores and be 10 years old in average.
Also, I am not sure - if I use one thread per lobby, how to determine how many games can run parallel and how many players/observers can reasonably attend one gamelobby at once.
What bothers me is that even if I test the limits on my machines that doesn't mean that it'll work elsewhere.
So, let's talk numbers.
Say I want to run 2, 20 or 100 games parallel without any observers, would you recommend option 1 or option 2?
Now we add observers, and now we add observers can also chat, what architecture would now be more reasonable and what do you think are reasonable limits then regarding the amount of parallel gamelobbies/running games and observers?
Additional question: When I have the class of one thread hold a queue and the other one takes from it, will this slow down the thread of which' class a queue's element was taken, or is that irrelevant, and if so, due to what?