Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[David S. Miller]

David Lang writes:
 > 1a. for webservers that server static content (and can therefor use
 > sendfile) I don't see this as significant becouse as your tests have been
 > showing, even a modest machine can saturate your network (unless you are
 > useing gigE at which time it takes a skightly larger machine)

Start using more than one interface, then it begins to become
interesting.

 > 1b. for webservers that are not primarily serving static content, they
 > have to use write() for the output from cgi's, etc and therefor pay the
 > performance penalty without being able to use sendfile() much to get the
 > advantages. These machines are the ones that really need the performance
 > as the cgi's take a significant amount of your cpu.

CGI's can be cached btw if the implementation is clever (f.e. CGI
tells the web server that if the file used as input to the CGI does
not change then the output from the CGI will not change, meaning CGI
output is based solely on input, therefore CGI output can be cached
by the web server).

 > 2. for other fileservers sendfile() sounds like it would be useful if the
 > client is reading the entire file, but what about the cases where the
 > client is reading part of the file, or is writing to the file. In both of
 > these cases it seems that the fileserver is back to the write() penalty.
 > does anyone have stats on the types of requests that fileservers are being
 > asked for?

It helps no matter what part of the file the client reads.

sendfile() can be used on an arbitrary offset+len portion of
a file, it is not limited to just sending an entire fire.

Later,
David S. Miller
[e-mail]