Date: Tue, 26 May 1998 20:04:46 -0700 From: Brian Behlendorf <brian@hyperreal.org> To: kriston@ibm.net (Kriston J. Rehberg) Cc: freebsd-advocacy@FreeBSD.ORG Subject: Re: FreeBSD A Solution For Business Message-ID: <3.0.3.32.19980526200446.007f0bf0@hyperreal.org> In-Reply-To: <3626-Sat23May1998005302-0400-kriston@ibm.net> References: <199805230337.UAA02883@osprey.grizzly.com> <01bd85e0$2dccb1c0$f820aace@eliot.pacbell.net> <199805230337.UAA02883@osprey.grizzly.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Mark Diekhans writes:
>>
>> o A port of Netscape enterprise server would be a plus. Apache is
>> good, but there is a perceived need for a threaded server for
>> scalability. Maybe more preception than reality.
About half and half. Right now we're trying to finish up 1.3 so we can
move on to 2.0 work, which where we will be doing threading, and right now
the most attractive approach is looking like it'll be to base Apache on top
of Netscape's "NSPR" runtime, a cross-platform library for threading, I/O,
and most everything else you'd ever need to make a system call for. It's
been ported across a huge number of OSes and is part of the Mozilla
distribution, and also under (in our opinion) a really good license.
Threading will allow the server to handle a greater number of connections
given a fixed amount of memory; and it will make it easier to link to a
multithreaded library for something like Java. But other than that it's
not clear that threads will be a huge significant win over the multiprocess
model; and it will definitely increase the potential for instability.
Today, if you have bad code in your server module, the connection which
triggers a bug causing a core dump only affects a single connection. If
the server's multithreaded, the whole thing comes crashing down. Not
pretty! Sure, there are things like kernels that run forever without a
problem, but most people don't hack their kernels as much as they hack
their web servers.
Someone in the group already has a test implementation of Apache on NSPR.
It's not complete, a lot of things are broken, but it's looking very
promising.
>With just user-level threads, this isn't going to buy you much. But
>that's okay because almost nobody buys multiprocessor Pentium systems
>at this moment, so you'll get efficient use of resources in the web
>server process. That will change and it would help to have
>kernel-level threads to take advantage of the extra processor(s) if
>that web server were threaded; until then fork/exec is better for
>multiprocessor systems -- at least the way I understand it.
Oh yeah, another thing - we may address the stability problem by having an
"N by M" model, where there are multiple multithreaded server daemons for
robustness. We have to do a bunch of benchmarks to see what ends up being
optimal.
Final thought - some of us in the group really want to go in the direction
of building a very very simple HTTP handling engine in the kernel; all it
would do is simple URL->filesystem mapping and file serving, maybe with a
configurably-sizeable MMAP cache for optimization. It would pop requests
up to userland for anything remotely complex, like SSI's, CGI's, or
anything on the other side of the Apache API. Any good kernel hackers want
to help us architect this? It'd be nice to find a genral architecture so
we could build kernel modules for Linux, Solaris, and other OS's where this
would be a Good Thing.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19980526200446.007f0bf0>