Messages in this thread | | | Date | Thu, 25 Jun 1998 11:57:48 +0200 | From | Erik Corry <> | Subject | Re: Thread implementations... |
| |
On Thu, Jun 25, 1998 at 04:55:38PM +0800, David Luyer wrote: > I don't know the specification for a sendfile() but lets say it was > > sendfile(fd-in, fd-out, options);
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
| |