tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: mod_jk - Firewall connection dropping
Date Thu, 12 Apr 2012 08:37:51 GMT


Christopher Schultz <chris@christopherschultz.net> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Luke,
>
>On 4/11/12 5:17 PM, Luke Meyer wrote:
>> Just noticed what I was missing about connectionTimeout - it's the 
>> default for keepAliveTimeout. So, that clears that up.
>> 
>> Still don't think it's a "huge negative performance impact!" to 
>> disable connection reuse.
>
>Well, if you think that HTTP keepalives represent a "huge positive
>performance impact" (and I certainly do), then the opposite ought to
>be true: if mod_jk has to re-establish contact with the backend Tomcat
>server for every single request, that will definitely have a negative
>performance impact.

Nope. You are not comparing apples and apples.

HTTP keep-alive is nearly always between a client and a server across the internet.
mod_jk keep-alive is nearly always between a client and a server on the same LAN and often
on the same machine.

HTTP keep-alive has no support for checking the liveness of the connection before it is used.
mod_jk keep-alive supports cping/cpong and it is pretty much essential that it is used to
ensure requests aren't sent to dropped connections or Tomcat instances taken out of service.
The time taken for cping/cpong is very similar to that required to establish a new connection
(and both are very, very small when compared to the time taken to process a request).

keep-alive does not scale for BIO connectors which require one thread per connection. Tomcat's
BIO HTTP connector protects against thread exuastion due to keep-alive by disabling keep-alive
once 75% of the threads are in use. Tomcat's BIO AJP has no exhaustion against thread exhaustion.
Because mod_jk uses persistent connections folks often don't get that Tomcat maxThreads (on
each instance) must equal the total number of httpd threads across all httpd instances that
route requests to that Tomcat. Managing this corectly requires careful setting of timeouts
and, despite Rainer and others writing some great docs, folks still frequently get it wrong.

In short, disabling mod_jk keep-alive frequently has no noticeable performance impact (some
customers of mine reported a performance improvement!) and greatly simplifies configuration
- especially for those folks that don't have a complete grasp of all of the details. The notice
in the docs about "huge negative performance impact" is a nonsense that needs to be removed.
However, given the strength of feelings that were expressed when the diabling keep-alive feature
was proposed (that lead to that notice in the docs) I am not prepared to remove it as I don't
wish to start a commit war. I'd be happy if the notice was toned down rather than removed
but I'd  rather see Rainer edit it to something he his happy with than I just remove it.

Mark

>
>- -chris
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAk+F/dkACgkQ9CaO5/Lv0PAVDwCcDm6/dCbAqgi0oaWESDUuRGmW
>sdgAn1i/q8hHIQcthwqriOZVJYZy2m1j
>=Boq3
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message