32 is the value for maxWorkerThreads that we use in a variety of our 
(Java-based)
backend service Tomcat instances for the AJP pool tuning. Default values in
the hundreds proved to be too resource-hungry; and, empirical load testing
has often found a point of diminishing returns (on a typical app on typical
hardware, whatever that means to you - maybe not the same as what it means
to me) of around 32-64 threads (at some point, you don't increase throughput
by attempting more concurrency, and instead only increase latency.)   
  
  
 Best practice is to keep concurrency under control. I.e. you *could* scale
to 200+ threads, but if 32 can manage the same work in the same time when
you put a queue in front of those 32, then 32 (or whatever number) is the
preferable number. 
 

Reply via email to