you can get it that low if you try, but by default its in the teens. i
think phhttpd is in the 4-5 range, and could be far less if we could get
rid of the annoying fcntl()s by having an F_INHERITANCE flag that would
allos fds to inherit some flags from their parent. hpux has been doing
this for ages.
> way, and is in the 2.2 kernels since ages). For #2, it makes no sence to
> switch to userspace a lot, as userspace effectively would only increment
> some counter.
[a quick aside that Arjan is probably well aware of; if you have a
dedicated serving machine with lots of mem you can crank the per socket
write buffers into the stratosphere so that the kernel will pump more out
of them before asking userspace to full them]
> ph[h]httpd, as I understand it, reduces the number of syscalls by using
> pre-calculated headers, and reduces the number of context-switches by
> "grouping" events into blocks of async-RT signals. (Not to speak of the
> reduced overhead wrt select()/poll() implementations). It also seems to
> "bounce" all non-static requests to a modified Apache.
roughly, yeah. We keep a response cache so that going from the requested
url to data on the wire is a hash on the url. the poll info bearing sigio
signals give us a light weight way to further work on all our connections.
> I haven't benchmarked phhttpd vs kHTTPd yet, as I have not patched my Apache
> for phhttpd yet. (Zach: Can phhttpd run without these modifications, or run
> Apache without phhttpd afterwards?)
thats a current annoyance with phhttpd. the server backing it has to be
aware that its around. but with plenty of nice open source servers, I
don't think this is a problem :) just grab the rpm :) and yeah, you can
config the hacked apache not to care about phhttpd at all.
> programs, kNFSd is there to do this to remote processes over the NFS protocol,
> for the very same reasons (latency) as mentioned above.
no. nfs has lots of nasty caching/locking problems that make it far nicer
to put in the kernel, its vastly different than httpd.
> 175 pages long. kHTTPd could also have been done the Microsoft way, that
> is to do everything from interrupt-handlers. That would increase
> performance, sure, but it would blast all modularity to bits.
We can do this portably and with zero copy in time if we do clever things
with async io and kiobufs..
> I look forward to further improvements in phhttpd and have all
> confidence that in the end, Linux as a whole will become better from
> discussions like this (at least from the parts that use real arguments
> and facts).
yes, choice is a good thing folks :)
but we're veering far from discussion that is appropriate on l-k. I'll
post something here when phhttpd is ready to roll.
-- zach
- - - - - -
007 373 5963
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/