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
