On 17 Nov 2011, at 20:39, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----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. Auto-size or select-at-startup? I thought the latter, and that in worker mpm it derived from ThreadsPerChild. At least that's how I read the docs & Mladen / Rainer's previous statements on the topic. > 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. Right... but if MaxClients is 600 that's a lot of unused & open connections, no? > 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. I thought it defaults to 60 but becomes 600 in total because there are 10 pools, one for each worker. > >> 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). Correct, but if MaxClients is 600, what's the point of having more connections open to the backend Tomcat(s)? > 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? I saw behaviour I didn't expect at a customer. Made more complicated by other factors, so I wanted to clarify the expected behaviour. > Or, was this a capacity-planning Gedankenexperiment? > > - -chris > > PS Missed you (again) at ApacheCon. Get on a plane you lazy bum. Yeah. :(. Unavoidable customer work. > -----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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
