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/2010.www.foo.com.crt"
SSLCertificateKeyFile="/home/user/ssl/www.foo.com.key"
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?
Hi.
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 doing
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.
http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
