OK, I agree this opens up a lot of new possibilities. Even more
if you include a size_t length parameter. I was thinking it was
going to be a clone of NTs web-server-syscall, which as far as I
know is limited to sending entire files verbatim onto a socket.
> fd-in - file descriptor to disk file (? is this needed as a restriction)
> fd-out - file descriptor to any object
> options - eg, close on send completion, sync/async. etc.
All these options aren't pretty. I would hope you could do
without them. If sendfile blocks until it is complete, there
seems little point in having a close-on-send, and if you look
at Deans website, you can see that the question of closing a
TCP/IP socket properly is non-trivial, and probably not for
kernel-space-only.
There's also error handling, but I guess it can be handled in
user space like it is now. One interesting aspect is that we
suddenly have two fds in one syscall, which makes the errno
errors somewhat ambiguous. Which end got an IO error?
> > which is basically little more
> > than a benchmark. If you really have such a hugely loaded web server
> > you are likely to be doing lots of database lookups, cookie-controlled
> > variable content, shtml, other cgi trickery, etc.
>
> What about a heavily loaded squid proxy cache?
Possibly. But according to Squid's own doc, the primary problems
in Squid performance are
1) Not enough memory
2) Too slow disks
which as far as I can see aren't helped by sendfile. They also
say "CPU limitations are rarely encountered except in very large
caches". The same doc describes how to use clusters for large
caches.
see http://cache.is.co.za/squid/opt/performance.html
> Also, there's a hell of
> a lot of static web content out there you know. Images and the like,
> probably the bulk of web content by volume.
Yes, but is it the bulk of web content by server-CPU-time?
How often is the speed of the server serving static
web content really a bottleneck? There are so many other
likely bottlenecks, like disk bandwidth (sendfile doesn't help
here as far as I can see), CPU speed for cgi, bandwidth to the
net, bandwidth on your Ethernet, etc. Linux/Apache can easily
saturate a 10mbits Ethernet already, how many people actually
have a faster connection to the net?
> > And if you really
> > just want to serve static objects as fast as possible, a round-robin
> > DNS with multiple servers gets you more robustness and a solution that
> > scales above Ethernet speeds.
>
> "Why tune the OS when you can just spend thousands on more servers?"
A T3 is tens of thousands of dollars a month. Compared with this,
a couple of Linux boxes, which give you redundancy as well are
nothing.
> > Would we just be doing this to look good agains NT in webstones?
>
> No, we would be doing it to perform better, and looking good in webstones
That's cool, as long as we make something that the application
writers can use. If we depart from Posix, we'd better get it right.
-- Erik Corry- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu