> > 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? Chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
