httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: AsyncRequestWorkerFactor / Event Sizing / Closing Connections
Date Wed, 22 Feb 2012 21:34:50 GMT
On Wed, 22 Feb 2012, Rainer Jung wrote:

> Looking at the server status on running 2.3.15 one can see, 
> that about 50% of the async connections are in closing state.
> We created AsyncRequestWorkerFactor to control the amount of overcommitment 
> in terms of connections relative to idle workers we allow for each process. 
> The formula is
> Connections =
> ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers) =
> busy_workers + ((AsyncRequestWorkerFactor+1) * number of idle workers)
> Default value for AsyncRequestWorkerFactor is "2", so per default
> Connections = busy + 3 * idle.
> Now if the situation on turns out to be typical, 50% of 
> Connections are in closing state, but we don't expect those to need any more 
> worker thread. So the overcommitment would reduce from a factor of 3 to 
> something closer to 1.5, which isn't much.
> Would it be feasible to only count the number of non-closing connections, so 
> allow new connections for a process as long as
> Non_Closing_Connections <=
> ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers) =
> Comments?

That's certainly a possible improvement. Others are also possible. For 
example, it should be possible to count ssl connections separately and 
don't take them into account when calculating overcommitment.

Or currently, after a timeout during write completion, there is another 
wait time for a lingering close. I don't think we need the full 30s wait 
time here.

But there is also a bug that ap_start_lingering_close() is called from the 
listener thread but may block (PR 52229). Maybe this should be fixed first 
before doing more optimizations?

> A related question: again on not only the number of async 
> connections in closing state is pretty high, also the percentage of sync 
> connections in state "C" is about 50%! I don't really understand that, 
> usually (no big event experience yet) I see "C" only occasionally, not with 
> such a big percentage. E.g. on the EU mirror running 2.2 and having less 
> traffic there is hardly ever a "C" to notice. Is that an expected 2.4/event 
> difference, or is there something strange with the us network infrastructure?

Does do a lot of https? Maybe the "C" connections come from 
SSL? Also, cgi requests where the response does not fit into the write 
buffer are done synchronously since the recent change. Though probably 
those should appear as "W".

BTW, mod_status should show if a slot is http or https. That's IMHO more 
important thatn the HTTP version or even the method. And it would be nice 
if mpm event could display more statistics in mod_status.

View raw message