Re: [SQU] HTTP + khttpd/TUX

Alex Rousskov wrote:
>
> On Fri, 3 Nov 2000, Joe Cooper wrote:
>
> > I've been looking over the Linux khttpd and TUX code, and thinking on
> > how we can most easily, and effectively leverage the performance of
> > these http stacks.
>
> Could you please summarize the advantages of khttpd and TUX code
> compared to Squid? What is an http stack? Why is it the most efficient
> method of handling http? Is it possible to implement similar
> functionality in Squid or as a stand-alone library? What would it
> take?

'HTTP stack' is a term coined by the folks who pushed an http daemon
into the kernel, their argument being that as HTTP is as much a
well-understood and popular network protocol as TCP/IP it could very
happily exist in the kernel right alongside IP/IPX/etc., and provide the
same performance advantages that having the TCP/IP stack in the kernel
exhibits.

They've proven it with TUX by trouncing IIS at recent benchmarking
events (2.5x the performance, including dynamic content). TUX is a
seriously fast webserver, and is not limited by the same kinds of
problems as the standard khttpd (which can only server static
content...but very quickly).

The advantage to either of these over Squid is that they are fast.
Laughably fast. It's simply funny to compare benchmarks on equal
hardware between TUX and any other webserver (even Zeus and Win2k+IIS).
However, the TUX code still can't handle a lot of things that Apache can
(what those things are, I'm not qualified to explain) so TUX (and
khttpd) has a method for passing unanswerable requests untouched on to
the 'real' webserver on the same box in a pretty efficient manner.

Now obviously, this isn't suddenly going to solve our disk bottleneck
problems overnight...or our memory inefficiency issue...or a lot of the
other things keeping Squid from handling 500+ reqs/sec. But I think if
we can integrate the kernel level http stack in some way that can be
leveraged for Squid's usage, then we can see some measurable performance
gains.

TUX has been designed to be a library-able (if that makes sense)
system. It is possible to make tux() calls as a source of signals--I
believe, my knowledge of the code is weak, but it has been discussed in
the past on the TUX list wrt to someone else working on a TUX based
proxy cache in his spare time (no code, he was just complaining about
the complexity of a signal based proxy cache).

There is a userspace httpd called phhttpd that I'm pretty sure has many
of the same implementation ideas that TUX has (for some reason the two
are grouped in my mind, so I think at one time there was some
relation...both developers work or did work at Red Hat--so I'm sure they
at least knew about the others work). Here is a link (which seems to be
down right now, unfortunately):

http://people.redhat.com/zab/phhttpd/

Hope this clarifies, a bit.
                                  --
                     Joe Cooper <joe@swelltech.com>
                 Affordable Web Caching Proxy Appliances
                        http://www.swelltech.com
Received on Fri Nov 03 2000 - 19:30:55 MST