httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Mooney <r...@area51.verge.net>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 18:18:33 GMT

I've read through all the archives on this (well the last year or so :),
and I've yet to see anyone propose the following model.  Let me prefix
this by stating I've seen this model handle over 2000 simultaneous users
in a transaction processing enviroment on a pretty weenie machine with
good response time (although all connections were persistent and long 
lasting which could signifigantly change the model).  This is very simular
to a lot of the existing models, but is quite different in the actual 
implementation.  I know a lot of people feel that select() has a lot of
overhead, that may be but I haven't found good profiling stats that show
exactly how onerous it is (if someone has them I would e very interested).

Anyway...

Front End 
  [Preforking Select based daemon, hands listen socket off to another
   front end when full]

Backends 
  [Connect to the front end through messages queues {we used shared mem,
   but I'm not sure of the portability there - could be a big arguement}.
   Actually processes the transactions and hand them back through the
   front ends when done]

Benefits:
  - Abstraction of the callback "mess" into a relatively simple frontend
  - Abstraction of backend processes with a standardized message queuing
    system reaps "other" benefits in that it can easily be reused elsewhere.
  - Quite fast
  - Possibility of creating more tightly integrated server farms
  - Simplified programming for the backends (and only guru's hit the
    front end part, which is basically what happens now).
  - You can abstract the "frontend/backend" into either processes or
    threads (ok not really sure how thats a benefit).

Drawbacks
  - May actually be slower?  We won't know unless someone tries it, but
    given the way web traffic works the overhead MAY outweigh the gains,
    this would require carefull profiling/benchmarking.
  - Slightly more complex than the current model.

I'm not saying that this is the "way to go" or the fastest way or even the
best way.  I am saying I've seen it perform very well in a slightly different
enviroment that had certain analogies to the model at hand, and its worth
exploring.

> And before someone says "use multiple i/o threads like squid does": gee,
> why don't we just use threads? 
> 
> And before someone says "use multiple processes like zeus does": gee,
> we're already planning on that.  If you think a single process select
> based threading model is better, then you can build with mit-pthreads.
> 
> It all comes down to simplicity.  Callback/event-loop programming is not
> immediately obvious to all programmers.  If that's the model we used, it
> would become much more difficult for third party folks to integrate. 
> callback programming is such a different model that many third party
> libraries which do i/o can't be used.
> 
> yadda yadda. 
> 
> This is all in the archives somewhere.  It repeats about once every other
> month or so. 
> 
> Repeat the mantra:  correct first, fast second.  If you think you can do
> better I'd love to be proved wrong.  But if all you want is to max out a
> benchmark, then I think you're taking the wrong approach.

Mime
View raw message