Mike Wertheim wrote:
APR is definitely being loaded. The DLL is there, and the log says it's
being used.
My question was basically: If I'm using APR, can I assume that I'll get the
APR Connector, or do I need to explicitly specify that I want the APR
Connector? (I'm assuming the answer is 'yes' to the first question and
'no' the the second question.)
Also, I reduced the ConnectionTimeout from the 20-second default down to 5
seconds, and the app seems to work fine. Would it be advisable to reduce
it even further? Assuming that all of my app's users are on a decent DSL
connection or cable connection, could I get away with reducing it to
perhaps to 2 seconds, or just 1 second?
connectionTimeout
The number of milliseconds this Connector will wait, after accepting a connection, for the
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite)
timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard
server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds).
keepAliveTimeout
The number of milliseconds this Connector will wait for another HTTP request before
closing the connection. The default value is to use the value that has been set for the
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.
They are two different things. It just happens that the default value of the
keepAliveTimeout is the value of the connectionTimeout (it would not make much sense
otherwise).
The connectionTimeout comes into play in this scenario :
- a client establishes a TCP connection to your server, and then it does not send a
request, but just maintains that connection and waits.
Ever heard of DOS attacks ? This is a good way..
Personally, I think that the standard setting of 20 seconds is still quite high.
I cannot imagine why a client would set up a connection to a server, and then not send a
request for the next 20 seconds, unless it is a malicious client.
(Of course, some clients and some lines are slow, so don't reduce it beyond a reasonable
value).
But the keepAliveTimeout is the one I was talking about.
It comes into play *after* the response to each request has been sent. The server keeps
the connection open, in the hope that another request from the client would arrive on it,
before it has to throw away this connection and start all over again for the next request.
But if you know that in your applications, such a "follow-up" request can never come later
than 2 seconds after the first response, then reduce it, maybe to 3-4 seconds, to take
into account small network delays.
The point is : you want to avoid having to build up and tear down SSL connections more
than necessary; but you do not want connections and threads sitting doing nothing for too
long either. So this setting should be a good compromise, /in your situation/.
Take into account that your situation may change over time, so don't set things too sharp.
Change one setting at a time, a little bit at a time, and observe the result.
Many of these settings have indirect effects on others, so it can quickly become confusing
if you change several things at the same time.
And if there was one set of settings which performed best in all cases, then the people
who make and package Tomcat would have set those already in the default configuration (or
they would be fixed in the code).
On Fri, Dec 16, 2011 at 8:20 AM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:
From: mike.werth...@gmail.com [mailto:mike.werth...@gmail.com] On
Behalf Of Mike Wertheim
Subject: Re: keepalive issue
In my server.xml, I have this line which turns on APR:
"Enables" would be a better word; it does not force the usage of APR.
With this configuration, can I assume that the Connector that I'm using
is
the APR/native Connector (the 3rd one in the Connector Comparison table)?
No; APR will be used only if the .so (or .dll) can be found and loaded.
The Tomcat logs should tell you whether or not that happened.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail and
its attachments from all computers.
---------------------------------------------------------------------
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
