-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony,
On 2/18/2009 1:14 PM, Anthony J. Biacco wrote: > I'm using apache 2.2.11 with tomcat 6.0.18 and mod_jk 1.2.27 on linux > 2.6 x86_64. > I was using a prefork mpm in apache, but have now moved to the worker > mpm. > I have a question or two regarding mod_jk in light of this change. > > 1. I'm running with ThreadsPerChild at 25 and MaxClients at 500. So, > I understand this to mean my connection pool minimum size will be a > total of 13. (25+1/2). - From the JK documentation: " connection_pool_size This defines the number of connections made to the AJP backend that are maintained as a connection pool. It will limit the number of those connection that each web server child process can made. Connection pool size property is only used for multi threaded web servers such as Apache, IIS and Netscape/Sun. The connection_pool_size property needs to reflect the number of requests one web server process should be able to send to a backend in parallel. Usually this is the same as the number of threads per web server process. JK will discover this number for the Apache web server automatically and set the pool size to this value. For IIS the default value is 250 (before version 1.2.20: 10), for Netscape/Sun the default value is 1. " Sounds like your connection pool size will be fixed at 25 connections per httpd process. > And then that this will be divided between my 4 tomcat > backends fairly equally. If I'm reading the documentation correctly, the connection_pool_size is set for a particular worker, so if you have 4 separate workers (for 4 separate Tomcat instances), each with a connection_pool_size of 25, you'll end up with 100 ajp13 connections from httpd to Tomcat /per process/. So, if you are using the worker mpm and have 10 processes, then you'll have 1000 ajp13 connections from httpd to Tomcat. The stats you get from the jkstatus make it obvious that I don't know what I'm talking about. > 2. In tomcat, It seems that my threads keep increasing, though they're > not used. I thought that the connectTimeout in tomcat and the > connect_timeout/ping_timeout in mod_jk would stop this by closing idle > threads, but it does not. Eventually the threads in tomcat with reach > the max of 400 and stay there until tomcat is restarted. Is there a way > to resolve this? And more importantly, should I resolve it? Is there any > major memory/CPU inplications to it keeping its threads at the max? I seem to recall someone saying that (for the standard HTTP and AJP connectors) allocated request processors are never recycled. That is, once a thread is created to handle an incoming connection, it is never retired. If you use an <Executor>, I believe you can do real thread management and have your threads disappear when they are idle for too long. You might want to check the documentation for <Executor>: http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html You'll want to use the "executor" attribute on your <Connector> elements to have your connectors use the named executor for thread management. > 3. What are the benefits to configuring mod_jk with --enable-EAPI and for > what circumstances should this be used? You are using Apache httpd 2.2, so EAPI isn't applicable. EAPI is only for httpd 1.3. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmcfGQACgkQ9CaO5/Lv0PDO0wCfQAcW+GeHXc29g+LtpFptVR7v XhEAoLkFDzdMK24ZP3nZwV7VjLa6B2MD =gtNt -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
