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).
>
> 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.
>
> 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.
>
Devil's advocate or not, the point is valid IMO. We can (and likely
will) have loads of fun reworking everything, but I'm +1 with Brian here.
Issac
