httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: sendfile() / Moving iol_socket to APR / abstractions in http_core
Date Thu, 11 Nov 1999 19:58:20 GMT
>
> Sounds great.   I actually have been wondering, though, about the
> interface for the sendfile method in ap_iol_methods
The current interface was an experiment and is going to change.  The
generalized sendfile API needs to accomodate sending an arbitrary number of
header buffers, the actual file followed by an arbitrary number of trailer
buffers. The new interface will look something like this:

ap_status_t ap_sendfile(struct iovec *headers, struct iovec *trailers,
ap_file_t *file, int flags)

The API needs to accomodate sending header and trailer data in a single
sendfile system call even if Apache does not initially use it.

> The current implementation also leaves a #ifdef
> HAVE_SENDFILE in ap_send_fd.
> So I think this leaves us with a few possibilities to consider:
> - Eliminate the #ifdefs in the main code by abstracting in APR.  This
> would mean using ap_sendfile in ap_send_fd and providing a new
> implementation of ap_sendfile for OSes that don't have the actual system
> call.
That 'new implementation' would be ap_send_fd_length and I'm not sure it
belongs in APR. Still, this is an idea worth exploring.

> There could actually be some good reasons for
> perfomance to have the sendfile method send the headers (particularly by
> setting the sockopt TCP_CORK on Linux), and I assume this is the reason
> why those args are there in the first place.
Yep, that's the reason. And I suspect the performance impact if very OS
specific. On Windows, system calls are mongo expensive so it's best to avoid
them when possible.

> However, we'd need to
> implement an ap_get_http_reader function to do exactly what
> ap_send_http_header currently does, but return a string instead of
> actually sending it.
You can hack it today if you want to do quick and dirty performance
comparisons (but do not check it in). Notice I flush the client buffer
before calling sendfile. I can easily grab the data pointer and length out
of the buff and pass them in on the sendfile call.

> This might come in handy for other modules or
> performance tweaks that want to send the header in their own way.
> - It seems to me that sendfile() and mmapped files are mutually exclusive
> strategies to quickly transmit an entire file.
Correct.

> If we moved the mmap code
> from default_handler to the new ap_sendfile, it would eliminate a lot of
> #ifdef'd cruft from the main module.  This would put all the
> platform-specific performance tweaks into APR where they, IMHO, probably
> should be.  We can always provide a NO_MMAP flag for ap_sendfile that
> ensures no memory mapping will be used, if in some case it would be
> undesirable.
> - Both Linux and FreeBSD allow you to specify an offset into the file in
> the sendfile() API.  I don't believe that Win32 TransmitFile() allows
> this.
It does. I don't recall the details though.

> By the way, I've heard that HP-UX also has a sendfile() call.  Is that
> accurate?
Yes, HP has sendfile.
> Any other platforms?
Yes, AIX has sendfile too. Unfortunately each version handles headers and
trailers differently. Bleh.

Bill





Mime
View raw message