Christopher Schultz <ch...@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-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

Reply via email to