Rainer Jung wrote:
Hey great, someone using recent version :)
I've been trying to stay current with the stable releases since upgrading
the app from httpd 1.3 and Tomcat 3.2.4 last year. I usually wait a
couple weeks to a month and watch the mailing lists after a release to
make sure nothing major snuck through QA.
ListenBacklog 2048
Wow.
I'm just guessing on most of these things. I suspect I copied
that from the httpd 1.3 + Tomcat 3.2.4 configuration, as I did
with a lot of the other numbers. I didn't create those old configs.
I just came in and tried to get the app working on Tomcat 6
and httpd 2.2 (and with the help of Brittain & Darwin and the
people on this list, I succeeded).
>Delete the connection_pool_size. Connection pools in mod_jk are local to
>httpd processes. Each process can only use as many connections, as it
>has threads to process concurrent requests. In your configuration this
>is 32. mod_jk asks httpd when starting about this number and
>automatically sets its pool size to the number of threads per process.
>You'll never need more. Only if you have very good reasons, that you
>want to lower this, you can configure a smaller number. Usually you
>don't want to do this.
please do also have a look at the docs page on timeouts for mod_jk.
I will do that.
>The 150 threads do not make a good fit to your MaxClients of 256. If
>your Apache is mainly forwarding requests to Tomcat, then it doesn't
>make much sense to allow 256 parallel connections to Apace, but only 150
>on the backend. That will result in some Apache processes being fully
>connected (32 connections) and some other not able to grow their
>connection pool to the full size, because they get errors when trying to
>connect.
Interesting. httpd is mainly connecting to servlets but those also request
images, javascript, style sheets and applets that get served directly by
httpd.
>Are the Apaches connected to each Tomcat, or only to "their" Tomcat?
Only to their own Tomcat. I even do the connection on the loopback
for security and (I hope) performance.
>If you separate your design into 3 disjoint Apache/Tomcat pairs, then you
>need to educate your LVS about correct session stickyness.
Already done. I'm pretty sure this setup wouldn't be working at all in
production if we hadn't since we don't have session replication (yet).
Thanks for the advice. I'm still digesting some of it and I'll be
looking at that
documentation again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
