Doesn't anybody have real world code that they can share that is attempting to use mt and the accept
I wrote the most basic bit of code that is not mt and performs reasonably well http://github.com/derekg/blackbd/tree/master but am looking at other situations where being mt would be a huge win. d On Fri, Jan 2, 2009 at 1:41 AM, Michael Carter <cartermich...@gmail.com> wrote: > > > On Thu, Jan 1, 2009 at 9:31 PM, Matthew Weigel <uni...@idempot.net> wrote: >> >> > I can see how this would be OK in cases where the app-level processing >> > is signifigantly more intensive than the HTTP parsing. But there are a >> > number of use-cases where this isn't the case. Take a comet server for >> > example: There's very little work for the other threads to do besides >> > idle for a while, then send back a small body. For these cases we need >> > *each* thread parsing HTTP requests. >> >> I'm a bit skeptical, to be honest. Although libevent and lighttpd are two >> completely different codebases, both take the same general approach to >> HTTP as >> a single-threaded, single-process server that eschews (where possible) >> select() or poll(). I think the results are pretty clear: parsing HTTP is >> not >> the bottleneck. :-) > > 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. 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" > > Let me describe a typical Comet use case that defies the single-threaded > HTTP architecture. I don't mean to beat this into the ground, I just want to > make it clear why someone might desire a multi-threaded/proccess HTTP server > where each thread/process parses input. > > Consider a live blogging server where users can stay at a webpage and > receive new posts/updates as the author makes them. If someone is covering a > live event, they might make a new post every 3 minutes on average. Each > user viewing the blog will make an HTTP request in the long polling style, > asking for a new event. The server will hold that request open for up to 30 > seconds if no new blog event occurs, and then send back an empty response. > The reason for the 30 second maximum has to do with firewalls and proxies > that shut connections down if they stay open much past 30 seconds. This > means that we'll have about ~6 out of 7 HTTP requests per user doing > absolutely nothing besides sending back an empty response. Also Consider the > case where half of your users have reached their browser connection limit > and must resort to normal polling (connection doesn't stay open) every 5 > seconds. In this case those users will make ~35 out of 36 requests that do > nothing besides HTTP parsing. > > When the blog author finally does make a post, he'll POST the contents to > our server, which will then send a copy out to each open connection. There > is no real processing involved beyond shuffling the bytes around. This > server spends about 99.99% of the time on I/O and parsing/generating HTTP. > If we have only one thread handling HTTP, then our app will only use one > processor core no matter how many additional threads we start up for other > tasks. > > -Michael Carter > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > > _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
