4 ms·

True for Rails 3, though you can enable threading (multiple requests per process). Rails 4 will likely default new apps threaded, but that option would still h

by rst 14y ago

True for Rails 3, though you can enable threading (multiple requests per process). Rails 4 will likely default new apps threaded, but that option would still have to be manually enabled for older ones. (I say likely because there are no formal releases yet, and it's still possible stuff will get pulled back.)

jlouis 14y ago
It was news to me that Rails operated in this way. It is a very weak concurrency model (to be precise: it is nonexistent). I knew that Rails was naive, but I had not dawned on me just how naive it is. It is interesting because then a system like node.js is a giant leap in the right direction - even if there are better languages out there. (disclaimer: I do Erlang for a living and often operate in highly concurrent settings.)
- wmf 14y ago
  Rails has a pure shared-nothing scale-out philosophy; it achieves concurrency with multiple processes. The fact that Heroku only runs one process per dyno by default is a shame though.
  - ericmoritz 14y ago
    As far as I know, the one process per dyno is not a restriction that Heroku puts on the application, it is an architectural decision of the application. Spawn up worker pool if you want > 1 req at a time.
  - jlouis 14y ago
    It won't help much for several reasons: Context switches are expensive. Very expensive. So your system runs overhead in the operating system. And you need to spawn a process per request. Pooling processes is a problem as well. If we only have 4 workers in the pool, then we have to queue requests on one of the 4 workers. But we don't know how expensive those requests are to serve, a priori. Even knowing the queue length or the queue sojourn time won't be able to divulge this information to us, only help a little. More workers just push the problem out further. If you want to be fast, you need: The ability to switch between work quickly, in the same process. The ability to interleave expensive work with cheap work. The two main solutions are evented servers: Node.js, Twisted, Tornado (both python); and preemptive runtimes: Go, Haskell, Erlang (of which Erlang is the only truly preemptive). I much prefer the preempted solution because it is automatic and you don't have to code anything yourself. There is a strong similarity to cooperative and preemptive multitasking in operating systems by the way. Events are cooperative. Do note there are no more cooperative operating systems around which you use on a daily basis :)

by rst 14y ago

jlouis 14y ago

It was news to me that Rails operated in this way. It is a very weak concurrency model (to be precise: it is nonexistent). I knew that Rails was naive, but I had not dawned on me just how naive it is. It is interesting because then a system like node.js is a giant leap in the right direction - even if there are better languages out there. (disclaimer: I do Erlang for a living and often operate in highly concurrent settings.)

wmf 14y ago
Rails has a pure shared-nothing scale-out philosophy; it achieves concurrency with multiple processes. The fact that Heroku only runs one process per dyno by default is a shame though.
- ericmoritz 14y ago
  As far as I know, the one process per dyno is not a restriction that Heroku puts on the application, it is an architectural decision of the application. Spawn up worker pool if you want > 1 req at a time.
- jlouis 14y ago
  It won't help much for several reasons: Context switches are expensive. Very expensive. So your system runs overhead in the operating system. And you need to spawn a process per request. Pooling processes is a problem as well. If we only have 4 workers in the pool, then we have to queue requests on one of the 4 workers. But we don't know how expensive those requests are to serve, a priori. Even knowing the queue length or the queue sojourn time won't be able to divulge this information to us, only help a little. More workers just push the problem out further. If you want to be fast, you need: The ability to switch between work quickly, in the same process. The ability to interleave expensive work with cheap work. The two main solutions are evented servers: Node.js, Twisted, Tornado (both python); and preemptive runtimes: Go, Haskell, Erlang (of which Erlang is the only truly preemptive). I much prefer the preempted solution because it is automatic and you don't have to code anything yourself. There is a strong similarity to cooperative and preemptive multitasking in operating systems by the way. Events are cooperative. Do note there are no more cooperative operating systems around which you use on a daily basis :)