Michael Carter wrote: > I'm not sure what you mean when you say that the results are clear. > Generally speaking, lighttpd deployments will use something like > round-robin fastcgi to allow the application logic to run in as many > concurrent (external) proccesses as is optimal, thus utilizing all of > the available cores.
Yes, which makes sense when the application logic is CPU-bound, by far the most common case. > Additionally, lighttpd supports exactly the > use-case I outlined where multiple threads process HTTP (though I'm not > sure how they avoid the thundering herd problem): > > From: http://redmine.lighttpd.net/wiki/lighttpd/Docs:MultiProcessor > "since 1.4.x we have support to spawn several processes to listen on > a single socket" http://redmine.lighttpd.net/wiki/lighttpd/Server.max-workerDetails THIS OPTION MOST LIKELY WILL NOT BOOST YOUR PERFORMANCE, ITS MOST LIKELY YOUR BACKEND Of course sometimes it isn't your back end, sometimes you really do need multiple cores working on the basic stuff. You describe one situation where it's possible (although I still doubt it), and I'm sure there are others. But, really, is libevent the place to solve those problems? The purpose of evhttp seems to be to make network servers easier to monitor - not take the web server world by storm. Hell, compare the analysis that Mathewson and Provos have done on the performance of libevent, and then look at the complete dearth of analysis on the performance of evhttp... -- Matthew Weigel hacker unique & idempot.ent _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
