Has anybody tried to create a Rack [1] handler? There are already handlers for CGI, FastCGI, Webrick & Mongrel. If nobody has created one I''m going to give it a try. AEM
On Jan 4, 2008, at 11:41 AM, aemadrid wrote:> Has anybody tried to create a Rack [1] handler? There are already > handlers for CGI, FastCGI, Webrick & Mongrel. If nobody has created > one I''m going to give it a try.I think the author of Rack may have already done this integration. See his announcement of Thin here [1]. [1] http://macournoyer.wordpress.com/2008/01/03/thin-a-fast-and-simple-web-server/
Thanks! Great find. Christian Neukirchen is actually the creator of Rack but Marc-Andre Cournoyer actually put together the dream team: EM, Mongrel''s parser and Rack. Just perfect. Thanks so much for the link. AEM On Jan 4, 2008 11:22 AM, Chuck Remes <cremes.devlist at mac.com> wrote:> > On Jan 4, 2008, at 11:41 AM, aemadrid wrote: > > > Has anybody tried to create a Rack [1] handler? There are already > > handlers for CGI, FastCGI, Webrick & Mongrel. If nobody has created > > one I''m going to give it a try. > > I think the author of Rack may have already done this integration. See > his announcement of Thin here [1]. > > > [1] > http://macournoyer.wordpress.com/2008/01/03/thin-a-fast-and-simple-web-server/ > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Adrian Esteban Madrid Lead Developer, Prefab Markets http://www.prefabmarkets.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080104/5b9cbc2e/attachment.html
On Jan 4, 2008 12:41 PM, aemadrid <aemadrid at gmail.com> wrote:> Has anybody tried to create a Rack [1] handler? There are already > handlers for CGI, FastCGI, Webrick & Mongrel. If nobody has created > one I''m going to give it a try. >I think the general idea behind Rack (a generic glue layer between HTTP servers and fulfillment frameworks) is a fine idea, but I don''t know much about Rack. Having reinvented this wheel plenty of times myself (including in the eventmachine_httpserver gem), my concerns would be these: - Building a hash with the CGI-style parameters is a brutal performance killer. If this is the approach, there needs to be a way for the app to tell the glue-layer only to send the parameters it will actually use. - It''s not enough to expect that the app will be able to generate a complete HTML response synchronously. There are two cases: a) You need to handle streaming, both for performance and to be a good citizen on the network (in case you''re sending a one-gigabyte response); and b) You need to handle cases where the app will be making secondary calls to one or more external servers in order to fulfill each request. Not to be tendentious about this, but I think we can all agree that threading is the wrong answer to these concerns for applications that have to really scale up and be really fast. That means some kind of lightweight concurrency mechanism is needed. In EM''s Unicycle, I use Deferrable to solve these problems, and it works great. Does anyone know how Rack addresses these points? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080104/0df8fa37/attachment.html
My question is how does it purport to be faster than evented mongrel when it uses EM and mongrel? That''s intense :)> a) You need to handle streaming, both for performance and to be a good > citizen on the network (in case you''re sending a one-gigabyte response); and > b) You need to handle cases where the app will be making secondary calls to > one or more external servers in order to fulfill each request. > In EM''s Unicycle, I use Deferrable to solve these problems, and it works > great. Does anyone know how Rack addresses these points?Do deferrables allow you to stream without using tons of cpu? That would be swell. Take care, all. -Roger
On Jan 4, 2008 7:40 PM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Jan 4, 2008 12:41 PM, aemadrid <aemadrid at gmail.com> wrote: > - Building a hash with the CGI-style parameters is a brutal performance > killer. If this is the approach, there needs to be a way for the app to tell > the glue-layer only to send the parameters it will actually use.Yeah. Part of the reason I still haven''t released Wisteria (http://wisteria.swiftcore.org) is that I keep messing with things like this. I might have a solution that I actually like, but I need to write some code and see how it holds up.> - It''s not enough to expect that the app will be able to generate a complete > HTML response synchronously. There are two cases: > > a) You need to handle streaming, both for performance and to be a good > citizen on the network (in case you''re sending a one-gigabyte response); and > b) You need to handle cases where the app will be making secondary calls to > one or more external servers in order to fulfill each request. > > Not to be tendentious about this, but I think we can all agree that > threading is the wrong answer to these concerns for applications that have > to really scale up and be really fast. That means some kind of lightweight > concurrency mechanism is needed. > > In EM''s Unicycle, I use Deferrable to solve these problems, and it works > great. Does anyone know how Rack addresses these points?My current Wisteria codebase, likewise, is using Deferrables, but it has a Rack compatibility layer available for use. Rack essentially works like Mongrel does. A Request object that have the info about the request (all params included), and a Response object with which one sets response headers and the data that makes up the response. It does have a facility to trickle out a response iteratively, a piece at a time, but not with any sort of concurrency.>From response.rb:# You can use Response#write to iteratively generate your response, # but note that this is buffered by Rack::Response until you call # +finish+. +finish+ however can take a block inside which calls to # +write+ are syncronous with the Rack response. Kirk Haines
On Jan 4, 2008 9:53 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> My question is how does it purport to be faster than evented mongrel > when it uses EM and mongrel? That''s intense :) > > > a) You need to handle streaming, both for performance and to be a good > > citizen on the network (in case you''re sending a one-gigabyte response); > and > > b) You need to handle cases where the app will be making secondary calls > to > > one or more external servers in order to fulfill each request. > > In EM''s Unicycle, I use Deferrable to solve these problems, and it works > > great. Does anyone know how Rack addresses these points? > > Do deferrables allow you to stream without using tons of cpu? That > would be swell. >Basically, yes. This is something I really ought to write a FAQ/HOWTO about, because it''s generally very useful. I don''t usually worry about CPU usage when sending exceptionally large responses from network servers. I worry about memory-bus saturation and latency. The trick is to send data as soon as you get it, and erase it from everyplace that buffers it, and move on to something else while you''re waiting for the next chunk to be ready. In EM''s case, it will buffer up outbound network data. But it will *also* avoid filling up the kernel buffers with data from any one connection. That can put a lot of pressure on memory. For a concrete example of what I mean, look at the send-file implementation that Kirk did in trunk/lib/protocols. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080104/13e99ddb/attachment.html
On Jan 4, 2008 7:53 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> My question is how does it purport to be faster than evented mongrel > when it uses EM and mongrel? That''s intense :)It''s easy. evented_mongrel has to conform its internals into the rest of Mongrel''s structure, so that it'' transparent, and the internals for Rack are lighter weight than for Mongrel. Mongrel is doing more stuff. Rack is leaner. Kirk Haines
What stuff in particular does Mongrel do that Rack leaves out? I''m not familiar with Rack very much. Evan On Jan 4, 2008 10:14 PM, Kirk Haines <wyhaines at gmail.com> wrote:> On Jan 4, 2008 7:53 PM, Roger Pack <rogerpack2005 at gmail.com> wrote: > > My question is how does it purport to be faster than evented mongrel > > when it uses EM and mongrel? That''s intense :) > > It''s easy. evented_mongrel has to conform its internals into the rest > of Mongrel''s structure, so that it'' transparent, and the internals for > Rack are lighter weight than for Mongrel. Mongrel is doing more > stuff. Rack is leaner. > > > Kirk Haines > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Evan Weaver Cloudburst, LLC
After playing with different webservers I decided to test raw delivery
("Hello World!"). Here are my results:
Event Machine 6,483 rps
Igor 5,148 rps
Thin 4,037 rps
Unicycle 3,846 rps
Serverside 3,320 rps
Mongrel 2,168 rps
And here you can find more details including the full results and the
scripts I used to get those numbers.
http://aemadrid.bingodisk.com/public/benchm.zip
Let me know if you have questions or want to run these tests yourself.
Sincerely,
Adrian Madrid
On Jan 4, 2008 7:53 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:
> My question is how does it purport to be faster than evented mongrel
> when it uses EM and mongrel? That''s intense :)
>
> > a) You need to handle streaming, both for performance and to be a good
> > citizen on the network (in case you''re sending a one-gigabyte
response);
> and
> > b) You need to handle cases where the app will be making secondary
calls
> to
> > one or more external servers in order to fulfill each request.
> > In EM''s Unicycle, I use Deferrable to solve these problems,
and it works
> > great. Does anyone know how Rack addresses these points?
>
> Do deferrables allow you to stream without using tons of cpu? That
> would be swell.
> Take care, all.
> -Roger
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
--
Adrian Esteban Madrid
Lead Developer, Prefab Markets
http://www.prefabmarkets.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080104/d12c34c0/attachment.html
On Jan 5, 2008 1:33 AM, Adrian Madrid <aemadrid at gmail.com> wrote:> After playing with different webservers I decided to test raw delivery > ("Hello World!"). Here are my results: > > Event Machine 6,483 rps > Igor 5,148 rps > Thin 4,037 rps > Unicycle 3,846 rps > Serverside 3,320 rps > Mongrel 2,168 rps > > And here you can find more details including the full results and the > scripts I used to get those numbers. > > http://aemadrid.bingodisk.com/public/benchm.zip > > Let me know if you have questions or want to run these tests yourself. >Adrian, I just sent you a private email about the attachment you originally tried to send. I wasn''t able to approve it for posting to this list, which is strange. But at any rate I see you''ve managed to solve the problem yourself by posting the scripts externally. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080105/4f432578/attachment.html