httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Apache 2.0 ideas
Date Tue, 03 Nov 1998 17:25:09 GMT
On Tue, 3 Nov 1998, Jim Gettys wrote:

> No, from userland, the fastest server will be one which caches (small)
> objects in memory, and then does a single send() of the cached memory.
> 
> File opens are expensive.  Save sendfile() for big objects, where the
> open overhead isn't significant.

No, you have to keep a cache of descriptors.  Then you completely avoid
having two fighting caches and inherit all the work that is already done
for the VM system.

Then you just need a system that scales well with large numbers of
descriptors.  Sun says Solaris 7 will handle "15000 times more open
sockets".  Can't figure out what that is 15000 more times than though; if
it is against 2.6, then a conservative estimate would say 7 would have to
handle at least 15 million.  Granted, that isn't necessarily per process.
Other systems are or will be making such things efficient as well.

I'm not too convinced that you are likely to get a huge win from merging
writes for multiple responses at the syscall level.  If you do, then I
would think that may show more that syscalls are too expensive on your
kernel.

I think there is a big advantage of sendfile() vs. mmap() in that the
implementation can pick the cheapest way to send small files depending on
the architecture.

> And yes, there was a crazy who thought putting X in the server was a win
> as well.  Didn't end up with better performance, and never got very
> stable (since a bug crashed your system, debugging was a pain).
> The CPU runs just as fast in user space as in kernel...

Yes, but a web server serving static content is far less CPU bound in
userland.  In fact, for the benchmark case, you can cut the processing CPU
down very very low.  Then the overhead for shipping the data can be
significant.


Mime
View raw message