Akins, Brian wrote:
On 9/21/08 2:17 AM, "Bing Swen" <[EMAIL PROTECTED]> wrote:
But an optimal
network i/o model needs a layer that maps a *request* to a thread, so that a
worker thread (or process) will not have to be tied up entirely with a
single connection during the whole life time of the connection. Instead, a
worker can be scheduled to handle different connections, which helps both
reducing the number of workers and the performance of request handling
(especially on slow connections).
I still want to see this backed up with real world experience. I know I
keep repeating myself, but in the real world, we have never seen the
supposed inherent performance problems in the worker model (1 connection = 1
thread).
At $work, we just upgraded RAM in what is essentially web server
machines, just because we are running worker MPM and expect lots of long
lived connections. It has a cost, and it isn't free.
It sounds great to theorize about the wonders of a completely event driven
or asynchronous model. However, it seems that this only nets real measurable
performance gains is very simplistic benchmarks.
What I view happening in the event MPM today, and where I would like to
go in 2.4, isn't a fully 'asynchronous model'.
It is much more of a hybrid, using threads (and processes) when running
most code, but allowing requests to be moved to an event queue, waiting
for IO, or a timer.
I'm all for making httpd faster, scale better, etc. I just don't want to be
extremely disappointed if we rewrite it all and gain nothing but a more
complicated model. If we get great gains, wonderful, but I'd like to see
some actually numbers before we all decided to rework the core.
No, in pure requests/second, there will not be a significant difference.
Today, a properly tuned apache httpd, with enough RAM, can keep up with
the 'fastest' web servers of the day, like lighttpd. Most of the
benchmarks where we do badly, is when apache httpd is mis-configured, or
running on extremely low RAM resources.
I think what we solve, is that with a slightly more async core and MPM
structure, we can signfigantly reduce the memory required to service
several thousand long lived connections.
Moving forward with a hybrid that lets you pull in async abilities when
needed seems reasonable to me.....
-Paul
