-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 4/12/12 4:37 AM, Mark Thomas wrote: > 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). I have not done any performance testing, but I would suspect that TCP connection setup is roughly equivalent to a CPING/CPONG. On the other hand, if the environment demands something like stunnel, then creating a new AJP connection also means an SSL negotiation, where a CPING/CPONG is likely to be much faster. > 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. That certainly is true: if one does not understand the network map (including connection counts), then one will get weird connection failures, etc. But the maxThreads setting has little to do with persistent AJP connections, except that (httpd) clients are less likely to be starved-out of the app server if all connections are ephemeral. > In short, disabling mod_jk keep-alive frequently has no noticeable > performance impact (some customers of mine reported a performance > improvement!) That sounds suspicious to me. > and greatly simplifies configuration - especially for those folks > that don't have a complete grasp of all of the details. I definitely agree with that. > 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. Fair enough. - -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+G8qgACgkQ9CaO5/Lv0PAG4QCcDkJnlXx47DeD1rt4HiWCIhBm Bj4AoIIpiw4+TlgR1xobK+E7C4dp4oQV =f4Ga -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
