-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pid,
On 11/16/11 7:20 PM, Pid wrote: > What I'm not clear on is whether the mod_jk worker > connection_pool_size is 60 per Server child, or 60 * 10 Server > children. mod_jk's connection_pool_size, when left to the default (which I think everyone should do) will auto-size for the situation. Obviously, in the prefork MPM, it defaults to 1 because you simple can't make more than one connection. For the worker MPM, I think the default is one connection per thread (per worker, of course), so if you have 600 total threads, you'll have 600 threads * 20 connections each = 12000. You can, of course, limit the number of connections by setting connection_pool_size to something smaller than the total number of threads * Tomcats you have. You'd only really want to do that if you were expecting a lot of requests to be handled directly by httpd with no communication with Tomcat. If you have 10% of your traffic going to Tomcat, then you might want to have your connection_pool_size set to 60 instead of (defaulting to) 600. > If MaxClients is still 600 and there is one Tomcat, one might > assume that allowing all 600 to go to that Tomcat is sensible - > but if there are two Tomcats, what is the behaviour? NB 600 to > each Tomcat would be more than MaxClients. mod_jk isn't affected by MaxClients, of course (aside from possibly the auto-default of connection_pool_size). If you have 600 worker threads and 1 Tomcat, I would expect 600 persistent connections from httpd to that one Tomcat instance. Doubling the number of Tomcat instances (by adjusting the worker, for example, to be an lb) will result in doubling the number of backend connections to 1200. >> If you have more than one worker, then the number of Tomcat >> instances is essentially multiplied. So, if you have 20 TC >> backends each with 2 workers assigned to them, then you'll 24000 >> connections instead. >> >>> Will this change If Tomcat instances start failing? >> >> Probably not -- mod_jk will just retire the connection and create >> a new one. If you are having load problems, you might make things >> worse with all this connection churn. > > Agreed. So, what was the problem you were trying to solve in the first place? Or, was this a capacity-planning Gedankenexperiment? - -chris PS Missed you (again) at ApacheCon. Get on a plane you lazy bum. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FcNcACgkQ9CaO5/Lv0PCIGACfbMFvTIacHTCO2sFavOSL2dzS pd4AoLbsnhHNclExBJ2TsyZN5ZA61JO6 =xePs -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
