tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: keepalive issue
Date Fri, 16 Dec 2011 08:10:50 GMT
Mike Wertheim wrote:
> I have a Java app running on Tomcat 7.0.21 with APR 1.4.7.  The app runs on
> 64-bit Java 7 Update 1 on CENT OS servers, with an A10 load balancer that
> sends traffic to the servers.  On average, each server is handling about 80
> requests per second.
> We are having problems with our network connections.  In server.xml, if we
> have keepalive on (maxKeepAliveRequests value greater than 1), then each
> server has way too many connections in the ESTABLISHED state, and the load
> balancer's NAT pool overflowsbecause it has too many connections to track.
>  If we have keepalive off (maxKeepAliveRequests value set to 1), then the
> number of ESTABLISHED connections goes way down and the load balancer seems
> ok, but the app starts refusing connections (we're not sure why).
> Does this make sense to you?  I'm not clear about why setting
> maxKeepAliveRequests="1" would have such a drastic impact on the site's
> performance (especially since most of our static files are on Akamai's CDN).
> Here is what our Connectors in server.xml look like:
>    <Connector port="8080" protocol="HTTP/1.1" URIEncoding="utf-8"
> connectionTimeout="5000" maxThreads="800"
> maxKeepAliveRequests="1"
> redirectPort="8443" />
>     <Connector port="8443" URIEncoding="utf-8"
> connectionTimeout="5000" maxThreads="800"
> maxKeepAliveRequests="1"
> SSLCertificateFile="/home/user/ssl/"
> SSLCertificateKeyFile="/home/user/ssl/"
>                 SSLCertificateChainFile="/home/user/ssl/intermediateCA.cer"
> scheme="https" secure="true" SSLEnabled="true" clientAuth="false"
> sslProtocol="TLS"/>
> Can anyone give me any insight on what the problem might be and how to
> troubleshoot this?
What I'll say below is not coming from any deep knowledge of the Tomcat code, rather from

some reasonable knowledge of HTTP in general.  Take it with the appropriate grain of salt.

Setting up an SSL connection is not trivial, compared to a normal TCP connection.
When you set mexKeepAliveRequeets to 1, you essentially force a new SSL negociation at 
each request, which seems quite inefficient.

On the other hand, when using the normal Tomcat <Connector> logic (as you seem to be
above), if KeepAlive is enabled, it means that one Tomcat thread will be dedicated to an 
incoming connection, to process the first request, and then it will "hang around" during a

certain time, in case there are more requests coming over the same connection.
If there are more requests in quick succession, it will process them, and this is 
efficient since no new SSL connection has to be built.
If there are no further requests after the first one however, then the thread will just 
sit around there waiting on that connection, until the KeepAlive timeout kicks in, the 
connection is closed, and the thread can return to the pool, to do something useful.
So if most of your client interactions consist of just one request, this may turn out to 
be rather inefficient, since you are blocking connections and threads to just sit around 
doing nothing, for the duration of the KeepAlive timeout.
If in addition this timeout is set on the high side (more than 2-3 seconds), you make it 
even worse, because that's the time the thread will sit around doing nothing.

KeepAlive is particularly effective when a client makes a request for an initial page and

gets it, and in that page are lots of elements which require further requests before the 
page can be displayed (think of a page with lots of thumbnails e.g.).
But in your case, you seem to say that many of these "secondary" elements might be on 
another server, so these secondary requests would never go to Tomcat, and it might well be

the case that the Tomcat threads spend most of their time waiting for the keep-alive 
timeout to expire.

Since you are under Tomcat 7, you may want to have a look at the Executor feature.
Again, I am not an expert, but if I understand correctly what this does, it avoids these 
"keep-alive" threads sitting around doing nothing, and allows them to be used to service 
requests on other connections in the meantime.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message