Troy.A Johnson writes:
> I am not "freaking out"

That was not directed at you, but rather people who know little about web
servers and assume Apache is the best web server available simply because it
is the most popular.

> Do the same limitations apply to the Apache 2.0.x series?

Yes.  On most popular free UNIX operating systems (Linux, FreeBSD), there is
little difference between a process and a thread.  In fact, on Linux (at
least up through 2.4), threads are implemented as processes (i.e.
LinuxThreads).

It is theoretically possible for the performance of a preemptive thread
based model to approach that of state threads model, but it doesn't work
that way in practice right now.  Here are a few interesting pages:

http://www.kegel.com/c10k.html
http://www.freebsd.org/kse/
http://cr.yp.to/lib/npthread.html
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
http://www.monkey.org/~provos/libevent/

> I think 1.3.x may be harder to "scale" upwards than some solutions,
> but for me it more than makes up for that in flexibility (which can
> also sometimes be a downside too, I know).

I don't consider Apache to be any more flexible than Zeus.  You can write
modules for Apache and ISAPI filters for Zeus.  There are nice features
unique to both pieces of software, obviously, but Apache certainly does not
have a monopoly on flexibility.

> But when you say "not
> scalable", I ask where the hard chalk line is drawn between
> the worlds of "scalable" and "not so".

I meant it in the sense of O(1) versus O(n).

> A nitpick, maybe, and it is
> simply your opinion, sure, but my opinion is that many folks find
> the old and crusty Apache 1.3.x multiprocess model "scalable
> enough".

As I said, for most people, Apache is quite adequate.

The original poster was having configuration difficulties.  I gave him a
recommendation based on years of experience working with web servers.  Two
people disagreed with that suggestion based on documentation that was likely
written years ago, which addresses concerns that are not relevant to at
least 99% of people running Apache, and certainly not relevant to the
original poster.  Hence my response about Apache's performance.

Summary: If you are running CGI scripts on a process-per-connection web
server, a few cached OS calls are the least of your performance worries.

-- 
David Phillips <david at acz.org>
http://david.acz.org/


_______________________________________________
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
http://www.mn-linux.org tclug-list at mn-linux.org
https://mailman.real-time.com/mailman/listinfo/tclug-list