-1

I'm using a TThreadPoolServer with a ThreadManager along with the PosixThreadFactory.

I set the number of workers to 100 which allows 100 simultaneous connections if my understanding is good.

I was wondering how far can I set the number of threads. So I tried to progressively increment the number and the max I could reach before my stress tests crash was 160.

My question is this: what are the parameters to take into account to correctly set the number of threads? Second question: is there a solution to handle more than this number (kind of clustering maybe?)

KLiFF
  • 382
  • 2
  • 18

1 Answers1

0

What are the parameters to take into account to correctly set the number of threads?

The maximum number of threads is not so much depending on a particular libary or product, it is more depending on how the threads are used. Just a few points to consider, without even attempting to provide an exhaustive list:

  • Each thread eats some resources by the pure fact of its existence. What the per-thread impact is in concrete, depends highly on the underlying OS and whether we talk about real OS threads, or things like goroutines.

  • Unless a thread is waiting for some event, it uses the CPU, RAM and I/O bandwith. What the impact is exactly, depends on the workload these threads are actually supposed to handle. Is the system as a whole primarily CPU bound, I/O bound or maybe bound to another shared resource?

  • Sharing resources across threads may lead to effects like lock contention, which have the potential to slow down the whole system the more concurrent accesses they have to handle. Again this depends on the nature of work and the architecture of the system.

Second question: is there a solution to handle more than this number (kind of clustering maybe?

Now that's a reeeeaaaalllly broad question on its own.

Community
  • 1
  • 1
JensG
  • 13,148
  • 4
  • 45
  • 55
  • Hi Jens, I understand your answer, the max number of threads is not something we calculate (easily) from the hardware configuration or OS technical specs. I'll have to do tests to know the limitation and live with that. My second question still makes sense for me. My server does not handle correctly more than 500 client, it simply crushes (not even simultaneous clients). The server itself does not do much yet. So, the question is, is there any encouraged way or architecture (master-slave, clustering) to make a stronger architecture when using Thrift? – KLiFF Mar 16 '16 at 16:40
  • Sure it makes sense. But it is hard to answer here on SO without narrowing it down to a single, clearly identified, solveable problem. In its current form there would just be too many possible answers. Writing volumes is something that SO is neither designed nor intended for. In short: you will need to schedule or load balance work between instances. If that is possible and how it could be done again **depends on the nature of the tasks**. -- Re the crash: A stack trace, some relevant code, and a good problem description is half way to a good SO question :-) – JensG Mar 17 '16 at 01:00
  • It is correct that the question may look very wide and may look like a non solvable problem. But I believe it is very clear and precise for someone who have already faced the same situation. I already know how to deal with scaling problems in general. What I need is an answer that comes from experience from someone who has already done this with Thrift. – KLiFF Mar 17 '16 at 08:46
  • [Recommended reading](http://highscalability.com/). Note that I don't mean that particular page, rather the entire web site. – JensG Mar 17 '16 at 19:06