On Wed, Aug 6, 2008 at 1:40 PM, ry <ry.d4hl at googlemail.com> wrote:> hey > i wrote a new web server today. it only works on yarv and it requires > rev but it''s mostly written in ruby (instead of c). > > http://github.com/ry/flow/tree/master > > it uses fibers and not threads. (maybe i''ll add deferred requets > later) > it should handle chunked uploads (and soon chunked responses) > it does pipelined requests too, i think > but not ssl. >Sounds awesome, especially now that Rails supports Ruby 1.9. What kind of performance are you getting with it? -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20080806/f40fa20e/attachment.html>
Why does it require 1.9? Just wondering. -R> Sounds awesome, especially now that Rails supports Ruby 1.9. > > What kind of performance are you getting with it?
On Wed, Aug 6, 2008 at 1:54 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> Why does it require 1.9? Just wondering. >Not sure if ry is on rev-talk so I''ll CC him. He''s using Fibers for handling requests, which is a Ruby 1.9-only feature. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20080806/1d0fdd92/attachment.html>
Fibers are definitely cooler :) I did some work recently on integrating a fibered web server with a fibered DB and it seemed to have success: here are some links of interest: http://oldmoe.blogspot.com/ # he''s been researching into it a lot :P http://209.85.173.104/search?q=cache:EcGf70nMwgwJ:betterlogic.com/roger/%3Fcat%3D35+asymy&hl=en&ct=clnk&cd=3&gl=us&client=firefox-a # my own work on it--deprecated so I deleted it, but it''s still around. I''d say fibers definitely have promise--if only as a way to avoid the pain of blocking DB IO. Note also that if you want to run asymy under rev you could do it using rev_em in the contrib folder of SVN. It seems to work. On Wed, Aug 6, 2008 at 2:01 PM, ryah dahl <ry at tinyclouds.org> wrote:>> On Wed, Aug 6, 2008 at 1:54 PM, Roger Pack >> <roger.pack at leadmediapartners.com> wrote: >>> >>> Why does it require 1.9? Just wondering. > > it uses Fibers. Which could be replaced with Threads, I guess, and > make it 1.8 compatible. But that would be less cool. > > Your request is dispatched as soon as the headers are parsed, but the > body of the request will still need to be read. In order to do this > you call > env["rack.input"].read > This yields the Fiber and jumps back into the request loop. Once data > is available it resumes the fiber. > > What would be cool is to break with the Rack protocol and provide a > completely evented interface for web frameworks (and do not use > Fibers). You''d just have on_body_chunk() callbacks and stuff. but i > guess people won''t use it unless they can''t just plug-in their old > stuff, so I''m doing the rack interface.Yeah a completely evented interface would definitely be the fastest thing on the block :) Unfortunately it''s somewhat unwieldy if your current code is something like a = School.find(1) if a.name == ''greg'' # do something a.steps[0].name = ''fred'' end would then have to be rewritten like School.find(a) do |a| if a.name == ''greg'' a.steps[0] do |step| step.name = ''fred'' end end end so really...layered. Plus learned recently that named blocks [which is what you''d have to use here--or is it?] are expensive in Ruby, so...fibers seem a much nicer solution :) Also note that rev comes packages with a fibered mongrel example, though I''d assume it''s similar to yours [and yours might be faster]. -R> > ry >
On Wed, Aug 6, 2008 at 3:49 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> Yeah a completely evented interface would definitely be the fastest > thing on the block :) > Unfortunately it''s somewhat unwieldy if your current code is something like > a = School.find(1) > if a.name == ''greg'' > # do something > a.steps[0].name = ''fred'' > end > > would then have to be rewritten like > School.find(a) do |a| > if a.name == ''greg'' > a.steps[0] do |step| > step.name = ''fred'' > end > end > end > > so really...layered.The real problem here is inversion of control that comes from any framework which is fundamentally Reactor based. What Fibers allow you to do is build synchronous interfaces on top of a Reactor framework. That''s specifically what Revactor, the Actor framework I built on top of Rev, is designed to do. However, it wouldn''t be too difficult to write synchronous wrappers for async database libraries on top of something like Flow, and it''d probably be a lot more lightweight than Revactor. In your example, the: a = School.find(1) ...would "block" as the async DB library makes a request. The fiber making the request would yield, and only be resumed after the async DB code has completed the query and processed the result. In fact, you could probably write an ActiveRecord adapter on top of such an API. Also note that rev comes packages with a fibered mongrel example,> though I''d assume it''s similar to yours [and yours might be faster]. >The Fibered mongrel example actually comes with Revactor (since Revactor takes care of all the I/O and Fiber scheduling), although I''m guessing it probably performs a lot worse than Flow. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20080806/ef486086/attachment.html>
On Wed, Aug 6, 2008 at 11:49 PM, Roger Pack <roger.pack at leadmediapartners.com>> here are some links of interest: > http://oldmoe.blogspot.com/ # he''s been researching into it a lot :Pactually i''ve been emailing him about it and wrote this after being annoyed that i couldn''t access my event loop in ebb from ruby.> Yeah a completely evented interface would definitely be the fastest > thing on the block :) > Unfortunately it''s somewhat unwieldy if your current code is something like > a = School.find(1) > if a.name == ''greg'' > # do something > a.steps[0].name = ''fred'' > end > > would then have to be rewritten like > School.find(a) do |a| > if a.name == ''greg'' > a.steps[0] do |step| > step.name = ''fred'' > end > end > endwhat if you had something where each class was an action. and the variables that were needed inside the template were methods. class Index < GetRequest def users Users.find(:all) end def posts Posts.find(:all, :last_week) end TEMPLATE = "/templates/users.erb" end (OR something) but if you didn''t use ActiveRecord but instead something else where find(:all) was nonblocking and returned, say, a rev io watcher to the database socket. When it completed it loads the results into @users and @posts then renders. structuring a web app in something like this would allow you to be very fast.> Also note that rev comes packages with a fibered mongrel example, > though I''d assume it''s similar to yours [and yours might be faster].i think it''s a client not a server? ry
On Wed, Aug 6, 2008 at 4:43 PM, Tony Arcieri <tony at medioh.com> wrote:> On Wed, Aug 6, 2008 at 3:49 PM, Roger Pack > <roger.pack at leadmediapartners.com> wrote: >> >> Yeah a completely evented interface would definitely be the fastest >> thing on the block :) >> Unfortunately it''s somewhat unwieldy if your current code is something >> like >> a = School.find(1) >> if a.name == ''greg'' >> # do something >> a.steps[0].name = ''fred'' >> end >> >> would then have to be rewritten like >> School.find(a) do |a| >> if a.name == ''greg'' >> a.steps[0] do |step| >> step.name = ''fred'' >> end >> end >> end >> >> so really...layered. > > The real problem here is inversion of control that comes from any framework > which is fundamentally Reactor based. > > What Fibers allow you to do is build synchronous interfaces on top of a > Reactor framework. That''s specifically what Revactor, the Actor framework I > built on top of Rev, is designed to do. > > However, it wouldn''t be too difficult to write synchronous wrappers for > async database libraries on top of something like Flow, and it''d probably be > a lot more lightweight than Revactor.Yeah I think that''s what we''re all advocating. A revactor style implementation for those pesky blocking DB calls. Come to think of it, this is indeed remarkably similar to revactor. =R