-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chris,
On 9/21/13 9:53 AM, chris derham wrote: >> >> 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? Anyone can edit the wiki -- after they request an account if one does not yet exist. Feel free to put-up a wiki page. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQDYJAAoJEBzwKT+lPKRY57oP/jhjkeQMBrmnqzlX2f90Elfn 7ll3iBeYqaZnFrEdzWXuVLtSc4YgAXYvdZmI29MNv8dI+caXrj5oywecGo5w7nn5 Tl1+gk6MO8tqxjs8mY5NjiTRL+mD9dBLYIGbztlA15+5V3oSzPyop0ydlWjtu+uk 4Sj99JAq175rvPxJB/ob9LDX0sETnM4F1fXfoZz55OkYGzaMMxcHigbSTmckdrWr cvLwSGn2zjdYAOZW+nWEM7iVnCR4MMXJSskIo67i5wOy89vzmUjS0tt1fl38a4GW lkf/qVLPtI8qOboLNGW1b1d6zrqYJULXovfmqEZ3h9KTcvQ1SSI9nrCxfFZZ6x2F k5pGWCPXrlnwxP9fKswR1LgYz+y9KynHaFNH2wVaCqX6WdXzK5Vk+GtbJc/IBZHJ pNnw4UhFFGk87tiW3wofM5wcgBQpZbQRgfkBSJ14GN/nnYHovQMVmiK+VqsvMU3m oSCGdgyYFdfqdPqGvo5J//BMX9zg9t4mk8vkCpNlvFR9onvZD9TyDYh8/5Kjlnfb cv96n5xV/DiLGq7gUTFnXSFouXUDLhe9bCRnH7npkY2njZcodLRnaMopVdei/Xj1 V+6H30RniIMSEDyRBfq4Db/yvGeG9XGFsHY9wl6XxOj3btp62MDWKjLdYoJ7ECWX Mnb9lHGSaxAw/1BjiEpf =aYEa -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
