> > > Apache 2.0 should be.
>
> "Should" isn't good enough, it will be nice to know, what kind of design
> will cause the performance to be increased so dramatically.
At present my apache development tree includes an abstraction I've called
the "multiprocessing model", for lack of a better term. In a nutshell the
MPM is responsible for assigning sockets to threads. Seems simple, but
that is one of the major areas where improvement can be made. At present
Zach could write an MPM for his sigwait stuff and we'd see an improvement
in speed on silly benchmarks. It'd also allow certain styles of in-kernel
caches to be integrated... Sun's and IBM's definately, but not khttpd.
Silly benchmarks are not good enough for me -- I care about real world
problems. So I've chosen to go a step further and add support for
asynchronous responses. This will let apache scale even better to the
zillion of long-haul client problem. (I don't think Zach can do the async
stuff until there is async sendfile... but I'm working on a portable
poll/pthread-based MPM that will work on linux and solaris at the least.)
The design allows any module to pretend that the code is entirely
synchronous (a la apache 1.x); while behind the scenes other modules can
be sending back asynchronous responses... the default_handler will be
fully async, which means all those static files will get the speedup you
all seem to want badly :)
If you want more info I suggest visiting the new-httpd archives for this
week, search for messages with "mpm" in the subject. (visit
http://dev.apache.org/) There's still lots to do.
Anyhow, I've posted about how I think an in-kernel cache should be
built... and the word "cache" is important... khttpd is an in-kernel
server, rather than a cache. It serves a different purpose.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/