tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chris derham <>
Subject Re: MaxClients and maxThreads
Date Sat, 21 Sep 2013 13:53:40 GMT
> 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)
> (1)
>                              |
>                              |- (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 accordingly.
> 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).

This type of question seems to come up once every 3 months on the
mailing list. Given that this is a beautiful explanation, perhaps "we"
could add this as a new section to the tomcat documentation - a new
"Performance Tuning" section?


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

View raw message