tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: TCP connections and HTTP sessions
Date Sat, 24 Jan 2009 22:34:12 GMT
tovaldez wrote:

> Actually HTTP sessions >> effective users, since each user has a 10 minutes simulated
navigation but the HTTP session is lasting a lot more (I think 1 hour by default in tomcat).
> What I thought was that using HTTP 1.1, I would have only 1 phisical connection to the
server for each user... This seems not to be, as if the same physical connection is used contemporarily
by more clients.
> I am asking if it could be a poor testing design or if we are wrong in our consideration...
To the best of my knowledge :
If your HTTP connections use "Keep-Alive", then one TCP connection will 
remain open for a while, between one browser and the server it is 
directly connected to.
What this "for a while" means precisely depends on a number of factors.
The server will time-out this connection (close it, and release the 
corresponding thread/child) if it does not receive new requests on this 
connection for a period of time (defined in the server configuration), 
or after processing a certain number of requests on that connection 
(also defined in the server configuration).
And all bets are off if between the browser and the server, there are 
intermediaries, such as proxies, firewalls, front-ends etc..
Some proxies/firewalls etc.. may even apparently use a single TCP 
connection to the back-end server, to serve requests from different 
clients. (I can't give you a precise reference, but this was mentioned 
in the last couple of months in a thread either here or on the Apache 
httpd user's list).

What it means is that Chris is right, and there is no immediate link 
between the number of clients that may be in a "virtual session" with 
your application, and the number of open TCP connections (or active 
threads) on your server.

In other words :
A client sends a first request to your server, and it is a direct 
connection.  The client is HTTP/1.1 capable, and indicates it wants a 
Keep-Alive connection.  So after the response is received, it will keep 
the connection open.  After this first request/response, the server will 
also keep the TCP connection open, for some seconds (not usually 
minutes), waiting for another request on the connection.  And at the 
server side, there will also be the corresponding child or thread 
listening for that next request.  If the browser sends one, it will thus 
be processed by the same thread/child, and the timer will be reset.
If the browser does not send another request after a few seconds though, 
the server will close the connection and recycle the child/thread.
So the next time the browser sends a request, it will have to re-open a 
TCP connection, and it will probably be another child/thread that 
handles this request on the server side.
The timeout is usually rather short, because otherwise the server would 
have umpteen threads/children that would be kept waiting for another 
request that might never come, and would be unavailable to serve other 
requests from other clients.

The point is that the Keep-Alive mechanism was not designed to "reserve" 
one server thread/child for each client browser over an extended period. 
  It was designed so that when a browser receives an html page 
containing 5 embedded thumbnail images, it could request these 
thumbnails right away over the same TCP connection, without having to 
re-create a new TCP connection for each of them, which saves overhead at 
each end.

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

View raw message