-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles,
On 10/23/12 3:01 PM, Charles Richard wrote: > I am doing load testing. I'm trying to ensure that our production > site can handle as much traffic as it possibly can and I'm trying > to make sure I refine my performance tuning skills on a test > environment. Here are some more specifics: > > Mod_jk is 1.2.31 That's a few versions behind. You might want to upgrade if you have the chance. > Settings in workers.properties: > > worker.worker1.type=ajp13 worker.worker1.host=localhost > worker.worker1.port=8009 > worker.worker1.connection_pool_timeout=180 Do you have a parallel timeout in your <Connector> on the Java side? > worker.worker1.lbfactor=1 If you aren't load-balancing, then this obviously doesn't have any effect. Also note that all of your settings are the defaults except for the connection_pool_timeout. If you end up setting up load-balancing, you might want to look into using a "template" worker. > I'm not sure how many threads would be good to handle how many > connections :) That depends upon response time under load. If you want to be able to handle 100 simultaneous requests, you need to make sure that you have enough threads to handle that, and that the hardware can get the work done that fast. > I'm just trying to understand more of the process so i can start > fine-tuning where I can. Right now, I'm trying to understand why > Tomcat could not respond anymore if threads are still waiting but > maybe with the server being cpu bound as it is, it's just taking a > long long time and everything is as could be "expected". That's the first time I heard you say "Tomcat could not response anymore". Is that actually happening? If you don't have the same connection pool timeout on both ends of the AJP connection, then you'll tie-up all your Tomcat request processing threads waiting on connections that will never receive any data, and you'll end up deadlocked. If you are load-testing, you might never notice since your AJP connections should all be getting exercise fairly regularly, and the 180-second timeout should never happen. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCHADMACgkQ9CaO5/Lv0PDo8wCeOKV2nnmNv3Vyz3rIECVb90dM q0IAnRLBpXFJF8WcDEc3YaKCALHmbjpv =sbpD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
