httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 02:01:45 GMT
Well, how about Zeus?  It's got bigtime performance, scales impressively,
appears to work well on SMP...

I was looking at thttpd, and I didn't think it would be difficult to add
in a module type scheme into it.  It only took me an hour to incorporate
the HSREGEX package and implement an anti-hotlinking handler.  In fact,
the entire code length is very tiny and straightforward.  Something like
12 functions to implement everything, and really obvious places to put in
various handlers... I don't know how Zues does it, but I figured it
wouldn't be too difficult to just spawn an extra thread for each processor
in the box, and have a separate client queue for each thread.  All the
info about each connection is held in one data structure, which in a
threaded implementation would be globally accessible... anyhow, just my

tani hosokawa
river styx internet

On Sun, 18 Apr 1999, Marc Slemko wrote:

> On Sun, 18 Apr 1999 wrote:
> > I was just wondering whether anyone's put any thought into making Apache
> > into a select-based multiplexing web server instead of the concurrent
> > process model that it currently is?  Looking around, I've seen a couple
> > servers (thttpd, mathopd, boa) that are way higher in performance... and
> > they look like they'd be really easy to code modules for.  I don't know
> No.
> If you look at nearly all those servers, you will see that they lack very
> important functionality, they have scalabaility issues on SMP systems,
> they have very restricted module functionality, can quickly fall over if
> you accidently do the wrong thing causing them to block, etc.
> That doesn't exclude the possiblity of having some special "fast path"
> type code for static content where you can have a single thread handling a
> bunch of static content being sent, etc.  But the general idea has to be a
> thread based server.  That doesn't necessarily mean a thread for every
> concurrent connection, but trying to avoid having each bit of general
> functionality be generic threaded code isn't worthwhile.

View raw message