4 ms·

Being embarrassingly parallel and always being parallel are two separate things. I don't see how the risk of bugs that, generally, show themselves under load wo

by nahname 13y ago

Being embarrassingly parallel and always being parallel are two separate things. I don't see how the risk of bugs that, generally, show themselves under load would ever make puma worth it. What is the advantage over unicorn? Slightly lower memory usage? My CPU and IO are always pegged way before memory is.

FooBarWidget 13y ago
The advantages depends on the workload. For a lot of applications, i.e. applications with CPU-bound, fast-running requests, multi-process behind a buffering web server (Phusion Passenger default style, Unicorn style) is fine and works great. Don't move away from that. When it comes to this kind of workload, both Phusion Passenger (open source and Enterprise alike) and Unicorn work better than Puma. While Puma can be configured to use 1 thread, Phusion Passenger still has better management tools and fault-tolerance features than Puma, while Unicorn also has better fault-tolerance features than Puma. For applications that utilize more blocking I/O though, e.g. applications that perform a lot of HTTP calls, you need a multithreaded or an evented app server, as well as an app written to support that concurrency style. Otherwise you will run out of concurrency very soon, and your app will spend a lot of time waiting on I/O instead of doing useful work.
- jrochkind1 13y ago
  I think that MOST web apps perform enough I/O to see huge advantages from concurrent request dispatch. Like, say, calls to the database. Most web apps do a significant amount of I/O, they are not strictly web bound. If the request-response loop spends a non-trivial amount of time waiting on I/O -- and most do -- then concurrent request dispatch has huge advantages. I tried to investigate/show that in these benchmarks: https://github.com/jrochkind/fake_work_app/blob/master/README.md https://github.com/jrochkind/fake_work_app/blob/master/READM... (And writing a ruby app to actually work right with evented/reactor-style request dispatch turns out to be way worse than multi-threading, in actual practice. http://www.slideshare.net/KyleDrake/hybrid-concurrency-patterns http://www.slideshare.net/KyleDrake/hybrid-concurrency-patte... ) (Your reference to 'blocking I/O' is confusing, I think -- that phrase means different and sometimes opposite things to different people/contexts. But it's not even neccesary to get into it for this discussion, you just mean 'I/O' at all, I think.)
  - FooBarWidget 13y ago
    Well, local I/O, and sometimes even LAN I/O, tend to behave close to non-blocking. The latency is very small, unless your database is under heavy load, but then you have other problems anyway. With blocking I/O I mean I/O calls which put the process to sleep for a while. This is in contrast to I/O calls which succeed immediately.
    - jrochkind1 13y ago
      In most of the web apps I've written, the majority of the request-response latency is waiting on the database, rather than cpu. I _think_ this is not uncommon? In other contexts, people talk about "non-blocking IO" and "blocking IO" to mean, well, 'blocking IO' is where the process or thread is _not_ put to sleep, it's not being switched out _even though_ it's waiting on IO. For instance, most ruby database drivers used to be broken in this way with respect to multi-threading, but were fixed to be "non-blocking IO", so threads would actually be unscheduled (even in MRI) when waiting on IO. For examples of this use of "blocking IO" vs "non-blocking IO" see http://en.wikipedia.org/wiki/Asynchronous_I/O http://en.wikipedia.org/wiki/Asynchronous_I/O (Ha, look what wikipedia URL did to "I/O"). That usage is pretty common, so I think your different use of 'blocking IO' is confusing.

by nahname 13y ago

FooBarWidget 13y ago

The advantages depends on the workload. For a lot of applications, i.e. applications with CPU-bound, fast-running requests, multi-process behind a buffering web server (Phusion Passenger default style, Unicorn style) is fine and works great. Don't move away from that. When it comes to this kind of workload, both Phusion Passenger (open source and Enterprise alike) and Unicorn work better than Puma. While Puma can be configured to use 1 thread, Phusion Passenger still has better management tools and fault-tolerance features than Puma, while Unicorn also has better fault-tolerance features than Puma. For applications that utilize more blocking I/O though, e.g. applications that perform a lot of HTTP calls, you need a multithreaded or an evented app server, as well as an app written to support that concurrency style. Otherwise you will run out of concurrency very soon, and your app will spend a lot of time waiting on I/O instead of doing useful work.

jrochkind1 13y ago
I think that MOST web apps perform enough I/O to see huge advantages from concurrent request dispatch. Like, say, calls to the database. Most web apps do a significant amount of I/O, they are not strictly web bound. If the request-response loop spends a non-trivial amount of time waiting on I/O -- and most do -- then concurrent request dispatch has huge advantages. I tried to investigate/show that in these benchmarks: https://github.com/jrochkind/fake_work_app/blob/master/README.md https://github.com/jrochkind/fake_work_app/blob/master/READM... (And writing a ruby app to actually work right with evented/reactor-style request dispatch turns out to be way worse than multi-threading, in actual practice. http://www.slideshare.net/KyleDrake/hybrid-concurrency-patterns http://www.slideshare.net/KyleDrake/hybrid-concurrency-patte... ) (Your reference to 'blocking I/O' is confusing, I think -- that phrase means different and sometimes opposite things to different people/contexts. But it's not even neccesary to get into it for this discussion, you just mean 'I/O' at all, I think.)
- FooBarWidget 13y ago
  Well, local I/O, and sometimes even LAN I/O, tend to behave close to non-blocking. The latency is very small, unless your database is under heavy load, but then you have other problems anyway. With blocking I/O I mean I/O calls which put the process to sleep for a while. This is in contrast to I/O calls which succeed immediately.
  - jrochkind1 13y ago
    In most of the web apps I've written, the majority of the request-response latency is waiting on the database, rather than cpu. I _think_ this is not uncommon? In other contexts, people talk about "non-blocking IO" and "blocking IO" to mean, well, 'blocking IO' is where the process or thread is _not_ put to sleep, it's not being switched out _even though_ it's waiting on IO. For instance, most ruby database drivers used to be broken in this way with respect to multi-threading, but were fixed to be "non-blocking IO", so threads would actually be unscheduled (even in MRI) when waiting on IO. For examples of this use of "blocking IO" vs "non-blocking IO" see http://en.wikipedia.org/wiki/Asynchronous_I/O http://en.wikipedia.org/wiki/Asynchronous_I/O (Ha, look what wikipedia URL did to "I/O"). That usage is pretty common, so I think your different use of 'blocking IO' is confusing.