tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: MaxClients and maxThreads
Date Sat, 21 Sep 2013 12:57:45 GMT
Daniel Mikusa wrote:
> On Sep 20, 2013, at 9:27 AM, wrote:
>> Is this a hard limit ?
> No.
>> So if there are 4 cores there can only be 800 
>> concurrent clients. None of our banks is calculating this like this and 
>> some have Apache and JBoss on the same machine which further limits the 
>> threads.
>> Appreciate any help.
>> Hi,
>>        I am following the instructions in 
>> to tune MaxClients in 
>> httpd.conf and maxThreads in JBoss Tomcat. 
>> " The recommended value of maxThreads is 200 per CPU, so here we assume 
>> the server is a single core machine. If it had
>>  been quad core we could push that value to 800 or more depending on RAM 
>> and other machine specs. The total threads
>>  is an aggregate value. If Apache and JBOSS are on the same server, and 
>> that server has four cores, then you would halve
>>  the maxThreads and MaxClients to 400 each."
> Don't base your performance tuning on values you found in an article online.  The author
of this article has no idea what kind of hardware you are running, what your application is
doing or what your needs are for the application.  By these metrics, I should setup 800 threads
on a quad core system, but if my application is only supporting 10 users that's way too many.
 Examine your needs, set the values you think will work and then load test to see how things
perform.  Adjust the settings further based on your load testing results.
> Dan
>> I have this question. Does this mean that maxThreads and MaxClients should 
>> both be equal to each other  ?
>> My configuration is this.
>> Machine 1 - JBoss and Apache(2 cores)
>> Machine 2 - JBoss(2 cores)
>> So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited 
>> by MaxClients in Machine 1 which should be only 200. Is that correct ? It 
>> is a bottleneck.

To add to what Daniel is saying, here is a little graphic representation, for one single 
client browser :

(browser) <-- HTTP --> (httpd + mod_jk) <-- AJP --> (tomcat) <--> (webapp)
                              |- (local resources) (2)

When the browser sends a request to httpd, one httpd child/thread is allocated to process

that request and return a response to the client.  That child/thread is busy with this one

request, from the time the request is received to the time when the response has been sent.
2 cases are possible :
a) the request is for something that can be served directly by httpd, without need to 
involve Tomcat.  That is the (2) above.  For example, in some configurations, static HTML

pages, images, stylesheets etc. are served directly by httpd, and only requests for 
"webapps" are forwarded to Tomcat.
b) the request is for something that has to be processed and served by Tomcat (the (1) 
above).  In that case, httpd + mod_jk will forward the request to Tomcat, and wait for 
Tomcat's response.
When Tomcat responds, httpd + mod_jk will return that response to the browser client.
While Tomcat is processing that request, you have one Tomcat thread busy processing that 
request, and one httpd child/thread waiting for Tomcat to respond.

So let's say that at the level of httpd, there are 1000 browser requests coming in every 
minute.  The number of httpd children/threads needed to handle this, depends on how long 
it takes httpd, on average, to process each request.  If it takes on average 1 second to 
process a request, then each httpd child/thread can on average process 60 requests per 
minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads

in httpd.
Now estimate (or better, measure) how many of these requests are being forwarded to 
Tomcat, and how long Tomcat needs on average to process such a request and send a response.
With the same kind of calculation, this will tell you how many threads you need in Tomcat.

Now to be on the safe side, double these numbers (if your servers support that), and try 
it out, /with your application/, measure what happens, and rectify the configuration 

The main point is : nobody except yourself knows exactly how your application works, how 
many requests are really served by httpd and tomcat, or how long it takes to process one 
request.  So nobody can tell you in advance how many threads/children you need in httpd or

Tomcat, to serve your volume of requests.

The best that the Apache httpd developers, and the Tomcat developers can do, is to provide

some "best guess" defaults, for some configuration that will, in their considerate 
opinion, be adequate for serving some average needs and not be very unbalanced.
And that's what they do, and that is why you should generally start with this default 
configuration.  And then, if you can see and *measure* that there is something wrong, 
start amending this configuration item by item carefully, and measure again after each 
change to see if it improves or worsens the situation.
There is no "one size fits all".
(If there was, then the developers would just set it as the default, and they would not 
need to provide any adjustable parameters).

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

View raw message