-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 McAfe,
On 5/25/2011 2:24 AM, McAfe wrote: > Christopher Schultz-2 wrote: >> AJP expects to have persistent connections. What is your Apache httpd >> configuration for StartServers/MinSpareServers/MaxSpareServers (for >> prefork MPM) or startServers/MinSpareThreads/MaxSpareThreads (for worker >> MPM)? > > Mcafe[20110523]: Did not configure Apache so far target on Tomcat (as for > research from google and test the result in Apache not much different) If Apache httpd is in it's default configuration, then you likely have either the worker or prefork MPM with a maximum simultaneous client MaxClients=256. >> What are you settings on the Tomcat side for your AJP <Connector>? > > Mcafe[20110523]: the follows is my setting for AJP <Connector> > > <Connector port="8080" protocol="HTTP/1.1" > maxThreads="150" minSpareThreads="25" maxSpareThreads="75" > enableLookups="false" disableUploadTimeout="true" > connectionTimeout="20000" > redirectPort="8443" /> The above <Connector> is for HTTP/1.1 and not AJP. Are you sure you are using Apache httpd in your setup? If you *are* using AJP on another similarly-configured <Connector>, since Apache httpd can handle 256 connections (you'll have to check your MaxClients setting) but Tomcat can only handle 150 connections, you have the possibility of httpd trying to forward a request to Tomcat that will fail because all of your AJP connections are busy. Since AJP connections are expected to be persistent, queuing the request in the TCP/IP stack is pointless: the request will never be handled. Instead, mod_jk fails fast and you'll probably get errors on the client (usually 500 or something similar). Check your mod_jk log (or configure one if you don't have one) and check to see if you are getting connection errors. >>>> From the research get to know minSpareThreads and maxSpareThreads, after >>>> set >>>> the configure it can handle more to 400 ~ 600 > >> minSpareThreads and maxSpareThreads shouldn't be used when using AJP: >> you should be using the exact number configured on the httpd side. >> Otherwise, you risk AJP connections churning. > > Mcafe[20110523]: Sorry no idea about this, as I'm new and wanted to learn > more. Fine tuning is not simple thing as just develop, hope you can give > me more example Use an executor: <Executor name="thread-pool" maxThreads="..." minSpareThreads="..." /> <Connector port="8080" protocol="HTTP/1.1" executor="thread-pool" /> > Mcafe[20110523]: Yup saw the default setting in the server.xml but unable > to find any useful example for the setting tried and the result not much > different (from the testing) > > <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" > maxThreads="150" minSpareThreads="4"/> That should work. Remember to set the "executor" attribute in your <Connector> to link them together. >>>> (2nd) From read 1 by 1 at the forums about Performance tuning - tomcat, >>>> some >>>> mention keep hit > 20k per seconds, how their do it? >> >> That depends a lot on what kind of load it was under. Serving static >> files is fast. Running database transactions is slow. Also, sizing the >> various pools can have an effect: you can max-out the throughput of a >> single client but still have plenty of CPU time and I/O time available >> on the server. If that's the case, make your connection pools bigger. > > Mcafe[20110523]: Yup, the webapps have to grab data from database and > return according. I'm interesting with "you can max-out the throughput of > a > single client but still have plenty of CPU time and I/O time available > on the server. If that's the case, make your connection pools bigger." > > Can you explain more? When you are making lots of requests, what does the CPU time and I/O throughput look like? Use a tool like sar to take samples and maybe graph them. Try taking samples during a load factor of 1 (just a single request-at-a-time) and then a load factor of 10 (10 requests at a time) and then a load factor of maybe 50 or 100. Compare the graphs to see if it looks like you are hitting a throughput maximum. If not, you can certainly handle more connections. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3dBB8ACgkQ9CaO5/Lv0PCMgQCdHbe573mrNjBux0fgnT9XLcwJ rqIAn1Fv5G+MbEouM/QD4dxxsS92e5xC =JS6Z -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
