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. (Disclaimer: yes, I'm partially playing devil's advocate here.) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
