tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [a bit OT] MaxClients and maxThreads
Date Tue, 24 Sep 2013 12:46:48 GMT
David kerber wrote:
> On 9/24/2013 12:11 AM, wrote:
>> Yes. That is probably the capacity planning part that involves think time
>> analysis and concurrency.
>> What Were They Thinking:
>> Modeling Think Times for Performance Testing
>> Tom Wilson
>> from Computer Measurement Group is what I plan to refer to. But don't 
>> know
>> yet how to mine this from awstats.
>> The Redhat link describes it like this
>> MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 )
>>          mod_jk default connection pool
>> Each worker has a connection pool and by default the connection pool size
>> is equal to ThreadsPerChild( 25 )
>> In the default case each worker has 25 connections multiplexed over 12
>> processes equaling 300.   Two workers will have  300 x 2 =600
>> connections to Jboss.
>> But I don't understand how one core with 2 hardware threads can support
>> 200 threads. I don't get that calculation. The problem is that when I 
>> draw
>> a throughput graph using think time analysis and concurrent connections
>> estimate I have to use 800 threads for a 4-core system if we have only
>> Apache there.
> As Andre says, it all depends on what those threads are doing, and that 
> in turn depends almost entirely on your application.  In some cases, you 
> might be able to support 800 threads per core, and in others 50 per core 
> might be overloading it.  You have to benchmark your application and 
> figure out what (if anything) is limiting you.

/yet) another way of looking at this : you are never really "overloading a core". A core 
works at a fixed speed, it executes basic instruction cycles at a speed which depends on 
the hardware clock of the system (2.3 Ghz etc..).  What happens is that if there is only 
one runnable program thread, then all the available cycles of the core can be dedicated to

that one thread, and the series of instructions to be executed for that one thread to 
provide the desired result (for example, a HTTP response by a Tomcat webapp) will 
terminate very quickly, and the response will be "very fast".
If on the other hand there are 200 runnable threads due to Tomcat webapps being triggered

by 200 simultaneous client requests, then this core will "time-share" between these 200 
threads, and each webapp response will take 200 times longer to finish, than in the 
previous case.  And if there are 500 runnable threads and only one core, then each 
response will just take 500 times longer than if there was only one thread.
And if there are 500 runnable threads and 2 cores available, then each response will 
possibly take only 250 times more time than if there was a single thread runnable.
(And I say "possibly" because webapp threads most probably do not only require CPU cycles

in order to provide a response; they probably also need memory and/or disk I/O, in which 
case having more or less cores is not the main element).

And then, have a look at one of your systems, with "top" (if you are under Linux) or the 
Task Manager (under Windows), and look at how many processes are running, apart from 
Apache httpd and Tomcat.  Well, all of those processes compete with httpd and Tomcat for 
the same cores (and the same memory and the same I/O bandwidth).  So how would that ever 
combine with some preset figure of "200 Tomcat threads per core" ?  What about these other

processes, do they not count ?

Now that can all be fine.  If you server receives 100 client requests per second, and each

request basically needs 1.5 ms of "system time" (*) to complete, then in total over that 
second you have only used 100 x 1.5 ms = 150 ms of "system time", and during the remaining

850 ms of that second, your system is idle and just doing nothing.
If you increase this to 500 client requests per second, then you will be using 500 x 1.5 
ms = 750 ms of system time every second, and you still have 250 ms available doing 
nothing.  But if you increase this to 1000 requests per second, then you would need 1000 x

1.5 ms = 1.5 s second of system time every second, and then clearly you have a problem : 
only 666 of those client requests can be served in 1 second (1000 requests / 1.5 ms), so 
334 requests will have to wait.
If during the next second, there are only 200 requests coming in, then that is still fine

: that next second of system time will be able to process 100 new requests + 334 delayed 
requests, and everything will still run smoothly, because there is some buffering in the 
system to absorb a temporary excess of requests.  But if 1000 requests per second is a 
permanent occurrence, then you have some choices :
- just decide that the clients have to wait
- improve your application to take less time
- or get a bigger system

There is no magic formula which will tell you in advance at which point your *system* is 
going to be overloaded (symptom: clients complain because they have to wait too long; 
other symptoms : your "top" display shows a permanent 100% CPU time, or 100% I/O wait 
time, or 100% memory usage).
You must benchmark and log, and analyse the results.

(*) that is the total of
- CPU cycle times in Tomcat and in your webapp
- CPU cycle time in the OS and in the other running processes
- disk I/O time needed by your webapp
- network I/O time needed by your webapp
- memory management time needed to provide memory to your webapp
- etc. etc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message