Jason Joseph wrote:
Christopher Schultz wrote:
.. lots of things ..
I can't imagine that MaxRequestsPerChild would contribute to this
problem. Maybe if you had MaxRequestPerChild set to 1 I might believe
it, but you have it set to "0" which means "children never die".
Wouldn't MaxRequestPerChild set to 1 force the server to start a new
process for every new HTTP request it got?
Yes, and that would be a terrible idea, performance-wise.
Just adding my grain of salt here, the way I understand how it works.
The KeepAlive feature is something that was added to HTTP, so that the
client and server would not need to create and tear down a new TCP
connection for each request, and thus improve performance.
The basic idea is that the same TCP connection can be re-used for
several /successive/ requests/responses between the same client and server.
(It also means that, on the server side, a "child" or "thread" of the
server will be kept busy, tied on this TCP connection waiting for more
requests, as long as the KeepAlive timeout has not been reached).
But this does not mean that the basic nature of HTTP is changed : on
that same TCP connection, individual request/response cycles are still
consecutive, not simultaneous. The only time when a browser would fire
off "simultaneous" requests, is if there were several windows or frames
open, each making its own connection, and requests on it.
There is no way the same browser window can make several requests at the
same time, receive several answers maybe in a different order (depending
on how long it takes to fulfill each request), and discriminate between
these answers to know which one corresponds to which request.
In other words, if I remember correctly the initial question, if the
browser fires off a series of consecutive requests (each time waiting
for the corresponding response), and one of these requests takes 30
seconds to fulfill, then the browser will wait these 30 seconds for that
particular response, before sending the next request.
That is the normal behaviour.
If you want to avoid that, you could for instance organise your pages so
that the long-duration request is made from within an <iframe> (which
should be considered as a separate window, and thus maybe will create
its own server TCP connection).
Just to be perfectly clear, let me give an example :
The first browser request is for an html page. It creates the TCP
connection to the server and sends the request. The response comes
back, in the form of the requested html page, and the browser starts
interpreting it and rendering it.
Now it just so happens that this html page contains 5 <img> tags
pointing to the same server.
Then, while it is rendering the initial page, the client browser can
keep using the existing TCP connection to send the first <img> request,
and receive the response (an image).
Then it finds the next <img> tag, and sends the next request, etc..
When it has finished rendering the page (and all its embedded images),
the browser does not send any request anymore for a while, and the
KeepAlive timeout expires, and the server can now close this connection
and release the child/thread.
Now if instead of a simple static image, the third of these <img> tags
happens to require a call to a back-end Tomcat, and generating that
image takes 30 seconds, then the browser will never continue to the 4th
<img> tag before it has this particular response.
But if this <img> tag happened to be inside a separate iframe, then this
iframe /may/ open another TCP connection to the server, get a different
child/thread, and be loading separately while the server continues with
the original window and page.
May.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
