Hi Fred-
What you're saying makes a lot of sense. As your automatic-flushing-
the-rails-3-1-plan article relates, for most rails interactions it's
difficult to stream because of all the evaluation that needs to
occur. Larger file downloads really are a special case. Using rails
metal to respond seems logical.
When I get a moment I'll create a brand new rails app and see if I can
get rails to stream as I'd expect; perhaps there is something in rack
that is preventing the streaming.
In rails 3, the render :text => lambda { ... } is definitely broken.
Thanks for the help!
--> Eric
On Oct 11, 2:19 pm, Frederick Cheung <frederick.che...@gmail.com>
wrote:
> On Oct 11, 7:44 pm, ehansen486 <ehansen...@gmail.com> wrote:
>
> > Nothing honestly moved the performance needle in a serious way.
>
> > I've finally come to the conclusion that rails does not stream out as
> > I'd expect. Here's a look at the perf stats rendered as the request
> > runs:
>
> it doesn't. Rails 3.1 will change some of that apparently (http://
> yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/)
>
> If you drop down to the rack level (ie write this as a rails metal)
> you should be able to stream responses - the rack body response can be
> any thing that responds to each. and rack will keep calling that each
> method until you're done.
>
> .The docs also say that render :text => lambda { ...} allows streaming
> but with various conflicting opinions form actual users (I've never
> tried that). This may also depend on the server (mongrel, thin etc)
> you use - it's no good you streaming data to rack if the next person
> down the chain sits on it until is done
>
> Fred
>
>
>
>
>
> > Rendered hgrants/_request_detail (2.2ms)
> > Rendered hgrants/_request_detail (3.9ms)
> > Rendered hgrants/_request_detail (2.4ms)
> > Rendered hgrants/_request_detail (2.3ms)
> > Rendered hgrants/_request_detail (242.7ms)
> > Rendered hgrants/_request_detail (2.2ms)
> > Rendered hgrants/_request_detail (1.9ms)
> > Rendered hgrants/_request_detail (1.8ms)
>
> > We went from an average 2ms up to 242ms then back down. I saw this
> > sporadically throughout the 1000 template renderings That suggests to
> > me that memory is getting garbage collected. Also, I'm invoking the
> > request from curl, and it reports no data downloaded until after my
> > logfile tells me rails has finished processing all records in the
> > view. The model IDs that result in the over-sized ms count vary from
> > one request to another, so I'm convinced there is nothing in the app
> > that is doing this. I even tested this by removing the call to the
> > HAML template and replacing it with a block of generated text and
> > observed similar behavior.
>
> > This is how I'm invoking HAML from the XML Builder template:
> > xml << render(:partial => 'hgrants/
> > request_detail.html.haml', :locals => { :model => model })
>
> > I also tried using this trick to try to get it to stream, but I
> > observed exactly the same behavior; no data showed up in curl until
> > all records had been processed.
> > render :text => (lambda do |response, output|
> > extend ApplicationHelper
>
> > xml = Builder::XmlMarkup.new(
> > :target => StreamingOutputWrapper.new(output),
> > :indent => 2)
> > eval(default_template.source, binding, default_template.path)
> > end)
>
> > (Also, in rails 3, the render :text with a Proc, rails 3 renders the
> > Proc as a to_str rather than calling it.)
>
> > This particular issue I can certainly work around but it's
> > disappointing if it's true that there's no way in rails to stream
> > output to the browser for large pages. And particularly disappointing
> > if PHP/Symfony can outgun rails for streaming. I've been using rails
> > since 2006 and most requests have fairly small responses so maybe the
> > answer is to defer to a different technology for streaming larger
> > files. But it seems like there should be a good solution for
> > streaming data and flushing the output stream.
>
> > Any help is greatly appreciated!
> > Eric
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
