httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: SSL downloads faster than non SSL?
Date Wed, 03 Aug 2005 13:11:48 GMT
At 04:54 PM 8/2/2005, Phillip Susi wrote:
>That's what it was, thanks.  Say, the name says 'Sendfile' but that doesn't exist on win32.
 Does apache call TransmitFile() instead or does it use some very poor library emulation of
sendfile()?  If it were using TransmitFile() I would expect it to not have any trouble saturating
the network.

In the APR library, yes, we translate 'apr_sendfile' to TransmitFile()
on win32.  Some other magic occurs to obtain a file handle which can 
be passed to TransmitFile.  But there are enough flaws in the TF() api
that perhaps this would be better defaulted to 'off'.

>FYI, I used wget to download the file without SSL and with sendfile disabled and it took
55 seconds and reported a rate of 11 MB/s.  I used a copy command to download the file from
the command prompt via the SMB mapped drive and it took 90 seconds.  I wonder what the heck
the deal is with all that fancy kernel mode redirector stuff not working out the way they
designed?
>
>I don't even see why the option for sendfile should exist on the win32 build, seeing as
how you can achieve the same performance using memory mapped zero copy overlapped IO, which
also would work with non disk files, such as an SSL encrypted connection. 

That is also available.  As you are aware TransmitFile() lives entirely
in the kernel, so there are far fewer user<->kernel mode transitions.

But if you turn off sendfile, and leave mmap on, Win32 (on Apache 2.0,
but not back in Apache 1.3) does use memory mapped I/O.

You suggest this works with SSL to create zero-copy?  That's not quite
correct, since there is the entire translation phase required.

>One of these days I'm going to have to take a little vacation from work and write an MPM
to do just that. 

:)  We seriously appreciate all efforts.  If you are very familiar with
Win32 internals, the mpm_winnt.c does need work; I hope to change this
mpm to follow unix in setting up/tearing down threads when we hit min
and max thresholds.  Obviously many other things in the (fairly simple)
win32 implementation can be improved.  Support for multiple processes
is high on the list, since a fault in a single thread brings down the
process and many established connections, and introduces a large latency 
until the next worker process is respawned and accepting connections.

Bill



Mime
View raw message