#266 HTTP Streaming
HTTP Streaming allows the browser to start processing the HTML response while the Rails app is still processing the rest of the request.
- Download:
- source code
- mp4
- m4v
- webm
- ogv
-
watch on iTunes
-
follow on Twitter
-
follow on Facebook
-
subscribe to RSS feed
Is it possible to use it with nginx or apache?
Yay! They finally ported all the problems PHP has to rails!
I see no advantage when your JS and CSS assets are properly cached by the browser, but a lot of problems.
Hi Markus,
I agree with you in case of rendering page layout. But imagine situation when you have to load huge amount of json data like rendering huge dynamic charts, maps, etc. In that case you are able to serve these data much quicker to users.
We have a CSV download that we generate while streaming it to the client. We can generate it at about 1megabyte/second so it makes sense to start sending it to the client as soon as possible. We are using a custom library to enable this today but I'm happy to see it available in Rails 3.1.
Does anyone know if it's possible to programmatically call the streaming yield?
You gain much speed for the first visit by a user and also the grouping of all js files and all CSS files into one compressed files reduces the number of requests by quite a bit.
A Rails 3 and before app would be quite slow from the viewpoint of the front end user experience and streaming should help a lot.
Doesn't streaming allow concurrent browser loading and caching? So for example, you can set it so your browser pulls in more HTTP requests at the same time or would this not apply to that?
@Markus
Plus caching of the files are beneficial. The version numbers at the end of the file that change when the file is changed would make it so the file is grabbed again when the user hits it. Otherwise it will remain cached and provide a faster experience.
If your app was to take 20-30 seconds to load the view the browser would hang and show no signs of a response until finished. With this it would load the title etc... and give the end user some sign that its working.
Although I would rather have it load a page saying "loading..." and fire of a ajax request for the data so the user has a complete page and then the data can take as long as it wants.
Even if the JS and CSS is cached, the browser won't start parsing and interpret until your page shows the inclusion. If your page takes 10 seconds to load, that will take 10 seconds. If are using streaming, that happens right away.
I don't think I'll be using HTTP Streaming much but its nice to have the option. What I'm really looking forward to are the upcoming screencasts on SASS and CoffeeScript!
Is streaming supported by Passenger?
Same question. Does the combo Apache/Passenger support treaming?
Yes, Passenger supports Streaming both on Apache and Nginx
Thanks Dan.
Yes, Passenger supports Streaming both on Apache and Nginx.
Hi Ryan.
No more ASCIICasts? I guess, I was the only fan of them.
Very nice redesign btw.
Ryan doesn't do the ASCIIcasts, that's handled by a fine fellow named Eifion Bedford. Check out his about page.
thanks for the note.
Hey Ryan! Another great episode :)
As for streaming it self i think that it's a great feature if you use it properly. Personally i would jump into it with my eyes covered ;)
@Markus: what kind of problems are you writing about?
@Ryan: i really appreciate the new look - it's amazing. Unfortunately I have to agree with Javi about the music :( Please, let it be more soothing :) (i'm sorry for pointing this out)
At first I thought this would be a way to display updates to an area of the screen when you fire off a long running task on the server from a specific web page and update the user about the progress. Say you wanted to keep the user informed about a process that reaches out to 4 or 5 other sources to assemble information, and you have a div where you want to report the status of each different source as it comes in. It doesn't sound like you'd use HTTP streaming for this though, right? Better to just use a combination of AJAX and JS here.
To that, have a part of the page update with status, you'd use ajax and polling on HTML 4 and sockets on HTML 5 (comet?). Rails is not good at it.
+1000 for SASS with Coffee ;)
Hey Ryan, would a good use-case for streaming be for a landing page like Groupon, where the background image is very large and could take some time to load? Or is it more for javascript intensive pages?
does 3.1 now give you error pages in development mode?
Great screencast and nice addition.
@Ken Hart: I guess it depends on your page structure. If your page rely on lots of heavy JS and CSS and this big background is simply for extra eye candy, I believe loading it after all the rest to be a better choice. However if your page have only this big image as heavy thing, yes, streaming will be great as starting it's download as soon as possible, ending up with a faster page load.
Great post Ryan!
While this is very exciting, I can see that people are unsure just when and where this technique should be applied, and if it should now take precedence over other performance best practices.
My advice would be to make sure you are doing all of the 'other' performance tuning things first, as they are generally easier to implement, easier to understand, and more battle tested. (gzip, combine/minify, leverage browser cache, optimize images, defer loading js, use ajax where it makes sense ... etc)
I would focus on all the stuff recommended by yslow, page speed, dynatrace, et al, first, as that stuff can be implemented right now, on any server, regardless of browser/mobile, proxy, whatever.
So when DOES it make sense to use streaming?
When you can give the user something to look at quickly and defer expensive processing for a bit later. Maybe you have a certain amount of 'chrome' at the top of your site, and you want to get it in front of your user quickly so they can orient themselves to the task at hand (google, yahoo, amazon, walmart, etc). Combined with browser caching, the page will load all of the stuff it has very quickly.
This functionality has been in php for awhile, and performance expert
Steve Souders notes on his site that while the gains can be quite significant, there are many issues that people run into when trying to 'Flush the document early'. (he even created a series of test pages to show how it works, and the problems related to gzip, parallel downloads, etc)
You can see a bit more of his chapter from the book 'Even Faster Websites' on google books but I recommend buying both of Steve's books, as well as High Performance javascript by Nicholas Zakas. (of all the programming books i buy that instantly become stale..books on performance do not)
I thought the idea of streaming wasn't to show the user a part of the page, but to have the browser start parsing and interpreting CSS and JavaScript while the server is still running that complex and heavy query.
Just FYI, in my 3.1 rc6 app I'm getting
DEPRECATION WARNING: stream class method is deprecated. Please give the :stream option to render instead.Yeah, I'm getting the same. It means that we have no enable streaming per action with an explicit call. Looks ugly, I wonder if streaming is regarded as an exception.
When running the curl command I get this error:
Anybody knows what's going on?
It's pretty important to note that HTTP streaming doesn't work with HAML: https://github.com/nex3/haml/issues/436
If anyone is trying to figure out why their Rails application being served by Passenger just isn't streaming data, you should know that Passenger 3.0.11 introduced a new setting that breaks streaming by default.
PassengerBufferResponse
the
streamclass method has been removedsee this issue
and from rails api docs
:(