tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: concurrent connections with mod_jk/apache/tomcat
Date Fri, 05 Jun 2009 16:50:47 GMT
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.

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

View raw message