5 ms·

"For a Rails app, each dyno is capable of serving one request at a time." Is this a deliberate design choice on Heroku's part, or is this just how Ruby and Rai

by anon640 14y ago

"For a Rails app, each dyno is capable of serving one request at a time." Is this a deliberate design choice on Heroku's part, or is this just how Ruby and Rails work? It sounds bizarre that you would need multiple virtual OS instances just to serve multiple requests at the same time. What are the advantages of this over standard server fork()/threaded accept designs?

kawsper 14y ago
It is how Rails server behaves in itself, but that is also how Heroku tells you to do it. Rails can be served with Unicorn ( http://unicorn.bogomips.org/ http://unicorn.bogomips.org/ ) which is a forking app-server. I do believe there was a trick a while back where you could get Heroku to run a Unicorn process on a dyno to get more requests out of it. The process is described here: http://blog.codeship.io/2012/05/06/Unicorn-on-Heroku.html http://blog.codeship.io/2012/05/06/Unicorn-on-Heroku.html
- anon640 14y ago
  Isn't this kind of a step backwards? Is Rails really that great that people are willing endure these kinds of limitations just to use it?
  - kawsper 14y ago
    Rails server is mostly for development mode. When deployed I think most people use either Unicorn, or throw their applications on JRuby that runs on the JVM with some kind of appserver. JRuby have this advantage of being multithreaded, so you can parallelize within a single process, and don't rely on forking. Stock Ruby with MRI have a GIL, and as far as I know only runs on one core. The limitations of stock Ruby is being worked on, but there is still a long way.
awj 14y ago
Rails is commonly run as one or more application servers behind an http server that proxies requests to them. Rails itself doesn't manage threads or forked processes for accepting requests, so the only way it fits into Heroku's dyno model is as an app server per dyno. > What are the advantages of this over standard server fork()/threaded accept designs? It's simple to build and manage in that you don't have to worry about thread safety and can use the already built and tested proxy capabilities of existing web servers to distribute traffic.
dspillett 14y ago
I assume it is intended to keep the nods as simple as possible so easy to schedule. A node dies? Just kill it and you lose at most the one active request. Which is the least busy node to send th enext request to? That can be a lot harder to judge reliably than simply "any nodes doing nothing? I'll queue this request then".

by anon640 14y ago

kawsper 14y ago

It is how Rails server behaves in itself, but that is also how Heroku tells you to do it. Rails can be served with Unicorn ( http://unicorn.bogomips.org/ http://unicorn.bogomips.org/ ) which is a forking app-server. I do believe there was a trick a while back where you could get Heroku to run a Unicorn process on a dyno to get more requests out of it. The process is described here: http://blog.codeship.io/2012/05/06/Unicorn-on-Heroku.html http://blog.codeship.io/2012/05/06/Unicorn-on-Heroku.html

anon640 14y ago
Isn't this kind of a step backwards? Is Rails really that great that people are willing endure these kinds of limitations just to use it?
- kawsper 14y ago
  Rails server is mostly for development mode. When deployed I think most people use either Unicorn, or throw their applications on JRuby that runs on the JVM with some kind of appserver. JRuby have this advantage of being multithreaded, so you can parallelize within a single process, and don't rely on forking. Stock Ruby with MRI have a GIL, and as far as I know only runs on one core. The limitations of stock Ruby is being worked on, but there is still a long way.

awj 14y ago

Rails is commonly run as one or more application servers behind an http server that proxies requests to them. Rails itself doesn't manage threads or forked processes for accepting requests, so the only way it fits into Heroku's dyno model is as an app server per dyno. > What are the advantages of this over standard server fork()/threaded accept designs? It's simple to build and manage in that you don't have to worry about thread safety and can use the already built and tested proxy capabilities of existing web servers to distribute traffic.

dspillett 14y ago

I assume it is intended to keep the nods as simple as possible so easy to schedule. A node dies? Just kill it and you lose at most the one active request. Which is the least busy node to send th enext request to? That can be a lot harder to judge reliably than simply "any nodes doing nothing? I'll queue this request then".