httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Date Wed, 31 Jan 2001 23:21:39 GMT
On Wed, 31 Jan 2001 wrote:

> > The patch get around this nicely, however at a steep price on Apache for
> > Windows.  We take a 50% performance hit when serving files smaller than
> > AP_MIN_SENDFILE_BYTES because we cannot use apr_sendfile() and reuse the
> > accept socket.  I would like to consider alternate solutions such as:
> > 
> > 1. back this patch out entirely and suffer the small packets on the network
> > for the cases above (which are not that common).
> It is common.  Take a look at what the Adobe browser plug-in
> requests.  The last time I looked this made a lot of overlapping range
> requests.
> > 2. Ryan suggests tuning AP_MIN_SENDFILE_BYTES. To what?  500 bytes? The number
> > needs to be much smaller than 8192 where it is set now. Thoughts?
> As I said when I committed the change, we need to run tests, and tune the
> number accordingly.  I guessed at 8192, it is likely wrong, and I said
> that when I committed.  I haven't had the time to run any tests.  Feel
> free to run your own.  If nobody runs them, I will run the tests in a few
> weeks, after we go beta.  Arguing over the correct value without running
> tests doesn't really do us any good.  Let's run the tests, and use real
> numbers to get the answers.
> > 3. Bypassing this optimizationonly for byterange requests (or perhaps multiple
> > byterange requests)
> Again, let's get some numbers, and speak with real numbers and real
> performance.  I really believe this patch is required, we just need to get
> the cut-off right.

Question: how does mmap()+writev() compare with sendfile() for this kind
of usage? On the example given, the first page (4k/8k) of the file will be
faulted in, then a simple writev() will send the whole body, avoiding all
the seeks, syscalls etc?


View raw message