Messages in this thread | | | Subject | Re: Thread implementations... | Date | Thu, 25 Jun 1998 16:55:38 +0800 | From | David Luyer <> |
| |
Erik Corry wrote:
> In article <6msk1d$n4$1@palladium.transmeta.com> you wrote: > > > Now, I'm no NT person, but I suspect that we actually do want to have a > > "sendfile()" kind of thing just because it should be fairly easy to > > implement, and would offer some interesting performance advantages for > > some cases. No, it's not truly generic, but it is useful enough in many > > circustances. > > I'm a little curious as to which circumstances you are thinking of. > As far as I can see, it's a syscall for a single application (a > web server serving static objects)
How about... * ftp server sending out static objects * proxy cache serving requests * imap/pop with maildir mailbox format sending mail items * news server sending out articles to peers and clients * sendmail sending mail from queue
That's just some for programs who want to put a file from the hard disk to the network. Maybe sendfile() could be used for other things too - such as direct disk-to-disk copy without leaving kernel space, backups, whatever. If it's fully generic and supports network-to-network then I can imagine a tunnel/firewall daemon run from inetd which does
connect() sendfile() exit()
(moving the main data-pump type loop into the kernel where it can be properly optimized)
I don't know the specification for a sendfile() but lets say it was
sendfile(fd-in, fd-out, options);
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.
Many, many applications could make use of a sendfile() function in some way (assuming it doesn't close the connection after sending the file, or that connection close is controlled by a flag).
I think we need a clear definition of exactly what sendfile() is/does, but just about any implementation of it would have gains to various areas.
> 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? 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.
> 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?" I guess you think I should install a dozen Microsoft Proxy boxes instead of the one Squid cache - hey, it doesn't need the OS tuning and tweaking that I have to do to Linux to run Squid does it?
> 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 comes as a free extra.
David.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |