> William A. Rowe, Jr. wrote:
>> At 03:17 PM 2/28/2005, Paul A. Houle wrote:
>>
>>>On Mon, 28 Feb 2005 21:09:55 +0000, Wayne S. Frazee <[EMAIL PROTECTED]>
>>>wrote:
>
>> Oh boy - you don't know *what* you are missing :) Threads on
>> Linux barely differ from distinct processes, while on Solaris
>> they are truly lightweight.
>
> Well.. thats true for LinuxThreads.. but NPTL is a different and better
> story. (Requires newer glibc and a 2.6 kernel)
>
Yeah, but that's because Solaris has embarassingly bad performance
running Apache/prefork; I've seen Apache run an order of magnitude
faster on Pentium II machines that I've fished out of the dumpster
than on Sun servers that we spent $30,000 for.
(Not to bash Sun by any means... Solaris will embarass Linux about
as badly running most MTA's; it's not so much that threads are bad
on Linux, but that processes are incredibly fast on Linux -- NTPL
doesn't so much speed up threads on Linux as make it possible for
them to scale.)
I think there is a reason why it matters that there is uptake on
Apache 2, and that's so development can really move forward. Don't
take it personally, but I'm quite depressed that Apache is still
the dominant web server after all these years; the chief
competition, Microsoft IIS, isn't all that different functionally
from Apache.
I think of all the features that web site authors and developers
need that still don't exist in mainstream web servers; part of this
is in the area of "content management" and another major are is
authentication -- pretty much any serious interactive web site needs
a cookie-based authentication system with the features seen on big
sites like amazon.com and yahoo! and one of the reasons there is so
little code reuse on the web is that every application winds up
impementing it's own authentication system; if there was something
really good built into a market-leading web server, this picture
would change completely.
A lot of the problem is that the market for advanced web servers is
tiny. Looking at Alexa and applying a little guesswork, I get the
sense that there are probably 10,000 or so sites that get more than
one million hits per day; and if you're doing static pages, you
could probably multiply that by 30x before Apache starts becoming
performance limited on reasonable hardware.
The remaining sites that need to push the limits of Apache all have
different circumstances, and they'll find different answers; if
you're running a dynamic site with PHP and you're hitting the CPU
wall, really the only good answer is to build a load-balancing
cluster. People who are running mod_perl often really do have memory
problems (but there's enough instability in mod_perl, using processes
instead of threads makes all the difference between a server that
gives a 500 from time to time and a server that goes down regularly at
2 AM.) Java's got it's own bunch of problems.
In that sense, the market for higher-end web systems is going to be
fragmented enough that getting enough sites running the same software
to really standardize and make progress will be difficult.
The one 'generic' area where I think Apache/prefork isn't so
satisfactory is in serving large numbers of large files... On some
platforms you might get a factor of 2 or 3 better with worker, but
you'll do that again (and maybe more) with something along the lines
of mod_event.
Another area that fascinates me is the 'perchild' MPM. Having the
ability to segregate different parts of the server to different users
could be useful for some systems I run. (One of my projects is a web
server with 25 virtual hosts, one of which has about 100
subdirectories managed by I don't know how many different people;
some of these sites are running PHP apps, some are using the accounts
to archive old files.) Needless to say, between the limited UNIX
permissions model and running Apache under one UID, we've had to make
some compromises between security and having to answer support calls
continuously from people because "it doesn't work".
If perchild could be made smart enough to have different classes of
server: little lean ones that can handle static pages, other bigger
ones that can do mod_perl, that could be useful. Perhaps we could
have some hybrid between worker and prefork that make it possible to
run threadsafe and nonthreadsafe apps in the same server...
The critical thing is that Apache shouldn't forget that "prefork" has
it's strengths. I think the main reason that Apache is so reliable is
that a hand grenade can go off in one process and it doesn't hurt the
server at all. It took Microsoft IIS many iterations to find a
reasonable balance between performance and stability, and the
evolution of Apache MPM's is likely to face similar pitfalls.
