httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bill stoddard <b...@wstoddard.com>
Subject Re: [community] 2.3.0 alpha on October 1?
Date Tue, 02 Sep 2008 17:47:20 GMT
Akins, Brian wrote:
> On 9/1/08 8:11 AM, "Jim Jagielski" <jim@jaguNET.com> wrote:
>
>   
>> On Aug 31, 2008, at 9:49 AM, Bing Swen wrote:
>>
>>     
>>> To my knowledge, the "one thread per connection" network i/o model
>>> is a
>>> suboptimal use
>>>       
>> threads vs. events is certainly not, imo, a finalized debate
>> yet with a known winner or loser. Maybe 5-10 years ago events
>> had a "clear" advantage but today that is hardly the case...
>>     
>
>
> I have documented my vote on this in the past, but the "async is inherently
> faster" looks good on paper, but does not, IMNSHO, measure up in the real
> world. 
I completely agree, it's not a slam-dunk conclusion that async/event
driven connection management in an http server is clearly superior.
However, Bing mentioned Windows...  Apache on Windows is not a stellar
performer, especially compared to a server that fully exploits IOCPs, 
connection reuse and  TransmitFile.  The Windows MPM does use IOCPs (not 
optimally) and connection reuse.  The biggest inhibitor to Apache on 
Windows performance serving files is in the apr_sendfile implementation. 
   Calls to TransmitFile are broken into something like 64KB chunks in 
order to facilitate detecting send timeouts.  If you modify the call to
TransmitFile to always just send the whole file, performance sending
large files will improve dramatically.

There is also a difference between async i/o and event driven i/o.  The
former requires more discipline managing buffers across the async i/o
calls.  Windows supports true async network i/o; many unix distros do
not.  IMO, event driven is good enough. async introduces too much
complexity for questionable benefit.

Bill






Mime
View raw message