* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > yet another performance update - with the fixed 'heaps of stupid > > threads' evserver_threadlet.c code attached below i got: > > > > > evserver_epoll: 9400 reqs/sec > > > evserver_epoll_threadlet: 9400 reqs/sec > > > > evserver_threadlet: 9000 reqs/sec > > > > so the overhead, instead of the 10x slowdown Evgeniy > > predicted/feared, is 4% for this particular, very event-centric > > workload. > > > > why? because Evgeniy still overlooks what i've mentioned so many > > times: that there is lots of inherent 'caching' possible even in > > this particular '8000 clients' workload, which even the most stupid > > threadlet queueing model is able to take advantage of. The maximum > > level of parallelism that i've measured during this test was 161 > > threads. > > :) > > I feared _ONLY_ situation when thousands of thereads are eating my > brain - so case when 161 threads are running simultanesoulsy is not > that bad compared to what micro-design can do (of its best/worst) at > all!
even with ten thousand threads it is still pretty fast. Certainly not '10 times slower' as you claimed. And it takes only a single, trivial outer event loop to lift it up to the performance levels of a pure event based server. conclusion: currently i dont see a compelling need for the kevents subsystem. epoll is a pretty nice API and it covers most of the event sources and nicely builds upon our existing poll() infrastructure. furthermore, i very much contest your claim that a high-performance, highly scalable webserver needs a kevent+nonblock design. Even if i ignore all the obvious usability and maintainance-cost advantages of threadlets. > So, caching is good - threadlets do not spawn a new thread, kevent > returns immediately, but in case of things are not that shine - > threadlets spawnd a new thread, while kevent process next request or > waits for all completed. no. Please read the evserver_threadlet.c code. There's no kevent in there. There's no epoll() in there. All that you can see there is the natural behavior of pure threadlets. And it's not a workload /I/ picked for threadlets - it is a workload, filesize, parallelism level and request handling function /you/ picked for "event-servers". Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/