Why Rails 4 Live Streaming is a Big Deal • Hacker News Board

Re: Why Rails 4 Live Streaming is a Big Deal

#51

Post by mapgrep » Fri, Aug 03, 2012, 5:33 PM UTC

masklinn wrote: post #12

jherdman wrote: post #8

Earlier quoted context omitted.

Ajax requires long polling, this PUSHES the response to the server, thus obviating the need for long polling.

> this PUSHES the response to the server Erm... it pushes the response to the client, not the server, and only pushes after a normal HTTP request. And of course, it also ties up a huge amount of server resources (total number of clients = total number of workers, since each client permanently ties up a connection forever). Phusion Passenger's docs recommend 8 workers/GB RAM, hope you expect users.

1. Long polling can tie up server resources too. There is a process on the other end of that long AJAX request. The mechanism for delivering the streaming connection to the client is orthogonal to the mechanism for handling that connection on the server.

2. You say a streaming connection "ties up a huge amount of server resources," but the whole point of the linked article is that this does not have to be the case; Node.js can (when used correctly) handle loads of connections in a single process, and Phusion Passenger is clearly trying to evolve their model to achieve similar if not fully comparable results.

Re: Why Rails 4 Live Streaming is a Big Deal

#52

Post by [deleted] » Fri, Aug 03, 2012, 5:40 PM UTC

malandrew wrote: post #43

bascule wrote: post #41

Earlier quoted context omitted.

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code. For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them. "Go or Node or Erlang" One of these th…

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets. The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

[deleted]

Re: Why Rails 4 Live Streaming is a Big Deal

#53

Post by malandrew » Fri, Aug 03, 2012, 5:46 PM UTC

PetrolMan wrote: post #48

malandrew wrote: post #43

Earlier quoted context omitted.

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets. The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

Please explain. I've actually had a pretty good time dealing with Sprockets. There are the occasional deployment issues but the benefits tend to more than make up for any frustrations.

Problems:

(1) Slow

(2) Sprockets' C-style require directives because the people working with ruby don't want to get their hands dirty with crawling the javascript AST and parsing out commonjs or even Harmony-ES module system requires.

(3) Incompatibilities between various JS-focused gems because of sprockets issues. Getting Require.js to work took a long time and then it took a lot longer to get the require.js gem to work with jasmine.js, and even then it ended up being a jerryrigged approach.

In general, sprockets is a mess with respect to Javascript handling versus what you can do in node.js.

Re: Why Rails 4 Live Streaming is a Big Deal

#54

Post by masklinn » Fri, Aug 03, 2012, 5:52 PM UTC

mapgrep wrote: post #51

masklinn wrote: post #12

Earlier quoted context omitted.

> this PUSHES the response to the server Erm... it pushes the response to the client, not the server, and only pushes after a normal HTTP request. And of course, it also ties up a huge amount of server resources (total number of clients = total number of workers, since each client permanently ties up a connection forever). Phusion Passenger's docs recommend 8 workers/GB RAM, hope you expect users.

1. Long polling can tie up server resources too. There is a process on the other end of that long AJAX request. The mechanism for delivering the streaming connection to the client is orthogonal to the mechanism for handling that connection on the server. 2. You say a streaming connection "ties up a huge amount of server resources," but the whole point of the linked article is that this does not have to be the case; N…

> Node.js can (when used correctly) handle loads of connections in a single process

Node uses an evented IO layer, that is completely orthogonal (and thus irrelevant) to streaming responses. You can stream responses with blocking IO, and you can buffer responses with evented IO.

> Phusion Passenger is clearly trying to evolve their model to achieve similar if not fully comparable results.

If you think that can happen, you're deluding yourself. Ruby+Rails's model means you need one worker (OS-level, be it a process or a thread does not matter) per connection. With "infinite" streaming responses this means each client ties up a worker forever. OS threads may be cheaper than os processes (when you need to load Ruby + Rails in your process) but that doesn't mean they're actually cheap when you need a thousand or two.

Re: Why Rails 4 Live Streaming is a Big Deal

#55

Post by masklinn » Fri, Aug 03, 2012, 5:53 PM UTC

xentronium wrote: post #37

masklinn wrote: post #12

Earlier quoted context omitted.

> this PUSHES the response to the server Erm... it pushes the response to the client, not the server, and only pushes after a normal HTTP request. And of course, it also ties up a huge amount of server resources (total number of clients = total number of workers, since each client permanently ties up a connection forever). Phusion Passenger's docs recommend 8 workers/GB RAM, hope you expect users.

> total number of clients = total number of workers, since each client permanently ties up a connection forever Totally up to your application server. Actual formula is number of clients = total number of threads. It is up to app server to handle parallel requests.

> Actual formula is number of clients = total number of threads.

That's what I said/meant by "worker", whether it's a thread or process does not matter, it pretty much has to be an OS-level concurrency primitive.

Re: Why Rails 4 Live Streaming is a Big Deal

#56

Post by ZoFreX » Fri, Aug 03, 2012, 8:59 PM UTC

masklinn wrote: post #13

ZoFreX wrote: post #11

Earlier quoted context omitted.

I'm actually quite excited about this, because I think it makes a lot of sense for this to be in Rails, for a couple of reasons. First of all, there aren't really any decent solutions for the problem in Ruby. There's a few projects with great potential, but nothing really mature - when I needed to do this, I went with cramp.in, which hasn't been updated in over 6 months now sadly. Node.js would unequivocally have bee…

> First of all, there aren't really any decent solutions for the problem in Ruby. Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3. > Secondly, even if there were mature Ruby equivalents to Node.js http://rubyeventmachine.com/ > I can still see a lot of benefit to doing this in Rails. Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails applic…

I was more meaning top to bottom, although I confess I never looked into the feasibility of just rolling my own thing with rack. I should have clarified what I was looking for, which was an event-based micro web framework.

Event machine is what's underpinning cramp, which is what I went for, and it does the job ok. The problems I had were to do with less than full support from the top to the bottom of the stack (basically the only server I could use was Thin, and there was no way to get anything working with Torquebox that I could find)

> Your Rails application can only have as many clients total as you have workers if they all keep a permanent connection.

So even though it's event-based, if I have 1000 clients long-polling (or SSE'ing, or whatever) that would tie up all my workers? I may have misunderstood what we were getting in Rails 4, then.

Re: Why Rails 4 Live Streaming is a Big Deal

#57

Post by amix » Fri, Aug 03, 2012, 9:12 PM UTC

sjtgraham wrote: post #15

amix wrote: post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

Actually not everything in Node is non-blocking. IO is largely non-blocking by but there is also blocking IO in Node too (synchronous file system functions). Not to mention you definitely will block by doing something computationally intensive in a single tick of the reactor loop. Have you ever written a non-trivial "real time" app in Ruby? I have ( https://github.com/stevegraham/slanger ). I think Ruby is actually v…

Having blocking computation is much better than having blocking IO - - especially, since most web applications spend most of their time waiting for the database/caching layer. And blocking computation can be solved in node using the clusters feature.

Re: Why Rails 4 Live Streaming is a Big Deal

#58

Post by [deleted] » Fri, Aug 03, 2012, 10:35 PM UTC

masklinn wrote: post #54

mapgrep wrote: post #51

Earlier quoted context omitted.

1. Long polling can tie up server resources too. There is a process on the other end of that long AJAX request. The mechanism for delivering the streaming connection to the client is orthogonal to the mechanism for handling that connection on the server. 2. You say a streaming connection "ties up a huge amount of server resources," but the whole point of the linked article is that this does not have to be the case; N…

> Node.js can (when used correctly) handle loads of connections in a single process Node uses an evented IO layer, that is completely orthogonal (and thus irrelevant) to streaming responses. You can stream responses with blocking IO, and you can buffer responses with evented IO. > Phusion Passenger is clearly trying to evolve their model to achieve similar if not fully comparable results. If you think that can happen…

[deleted]

Re: Why Rails 4 Live Streaming is a Big Deal

#59

Post by cageface » Sat, Aug 04, 2012, 1:35 AM UTC

bascule wrote: post #41

cageface wrote: post #9

Earlier quoted context omitted.

I think the problem is that Rails was designed to solve the web problems of 2005 and a lot has changed since then. The shift to single-page, JS-driven applications and large numbers of dynamic updates requires a different set of design priorities and the performance characteristics of Ruby itself are more problematic in this environment. In many cases it makes more sense to use something like Go or Node or Erlang tha…

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code. For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them. "Go or Node or Erlang" One of these th…

Knocking up a REST API in any decent web framework is easy. Rails makes it slightly easier.

It's good that things like cramp exist but async is really something you want to design into your language and framework from day one and not bolt on via libraries later.

Re: Why Rails 4 Live Streaming is a Big Deal

#60

Post by masklinn » Sat, Aug 04, 2012, 9:01 AM UTC

ZoFreX wrote: post #56

masklinn wrote: post #13

Earlier quoted context omitted.

> First of all, there aren't really any decent solutions for the problem in Ruby. Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3. > Secondly, even if there were mature Ruby equivalents to Node.js http://rubyeventmachine.com/ > I can still see a lot of benefit to doing this in Rails. Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails applic…

I was more meaning top to bottom, although I confess I never looked into the feasibility of just rolling my own thing with rack. I should have clarified what I was looking for, which was an event-based micro web framework. Event machine is what's underpinning cramp, which is what I went for, and it does the job ok. The problems I had were to do with less than full support from the top to the bottom of the stack (basi…

> So even though it's event-based

Rails is not event-based. An evented systems can have an n:m relation between workers and clients.

> I may have misunderstood what we were getting in Rails 4, then.

Yeah, or I did. As far as i understood, Rails 4 just adds streaming responses: the client starts getting bytes as soon as you start generating them (by calling `response.write` or whatever). That's not evented, that's just writing to the response stream, you can do that in CGI if you want.