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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
