Hi Chris, I do use load balancing on our production environment so I'll have to check out the parallel timeout you mention, I don't think I've read about this before.
As far as Tomcat hanging, my apologies, I discovered late yesterday that it was Apache reaching its MaxClients limit and therefore Apache was my bottleneck. After increasing the Apache parameters and looking at tomcat threads through VisualVM, this all looked a lot better. Cheers, Charles On Tue, Oct 23, 2012 at 5:38 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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 > >
