4 ms·

Puma: A Ruby Web Server Built For Concurrency

37 points by grk 15y ago

jarito 15y ago
This seems like a neat accomplishment, but why would I use it? There is mountains of work for standard configurations including security hardening, monitoring, configuration management, etc. What about this product makes it better than the other options?
mbq 15y ago
tl;dr it parses HTTP headers with Ragel, which is a really nice idea; the state machine part is a yummy bite.
- dnc 15y ago
  Correct me if I'm wrong, but I don't see how is this different from Thin, AFAIK it also uses Ragel for the same purpose.
  - towelrod 15y ago
    thin uses EventMachine and puma uses threads.
  - carmen 15y ago
    this is in the parser files in puma: * Copyright (c) 2005 Zed A. Shaw puma's README wording make it seem like the Ragel parser is some new thing unique to Puma, and doesnt mention Zed. no wonder he hatest rubyists also, thin has had a --threaded flag for years
    - mattgreenrocks 15y ago
      Thin's --threaded flag is still considered experimental. Also, spawning a native OS thread per incoming connection is not cheap, either.
      - getsat 15y ago
        At high numbers of concurrent connections, your thread stacks consume a non-trivial amount of ram, too.
- zedshaw 15y ago
  It is a really nice idea, which is why I used it in Mongrel and now it looks Puma is a fork of Mongrel so I'm doing it again!
juliennakache 15y ago
I'ven't looked at the code base, but I don't get how you're allowing true concurrency without any evented framework?
- mitchty 15y ago
  The same way every non-evented codebase does. Threads. https://github.com/evanphx/puma/blob/master/lib/puma/thread_pool.rb https://github.com/evanphx/puma/blob/master/lib/puma/thread_...
  - juliennakache 15y ago
    Then IMHO it's very unlikely to be "screamin" fast using the MRI
    - ssmoot 15y ago
      So don't use MRI. Events are not a substitute for Threads, and Threads are really not as hard as people would like to claim when you're working at the level of an application developer. Keep in mind that hundreds of thousands (wild guess) .NET developers have worked with both Threads and Events for years in WinForms and WebForms without much trouble. Because 99% of the time as long as you follow a few simple rules about what you're passing to an event, and you use built-in thread-safe collections along with the occasional custom double-lock, you're going to be safe. The framework takes care of most of it for you. Disclaimer: Having little experience with Node.js and some of the other new-ish evented frameworks, the following observation is probably at least somewhat off-base. But it occurred to me the other day that in a lot of ways many OSS projects are trending towards popularizing a model Microsoft mainstreamed (at least in my limited decade-plus experience). ie: "Delegate All The Things!" Wasn't really a fan of it then (there are definitely advantages, but I think you can make the claim it went entirely too far) and I guess that's what left a sour taste in my mouth when anyone brings up Evented programming as some sort of silver bullet. In addition to that, considering my experience with Thread Pooling and Events, it always strikes me as odd when they're presented as competing solutions. They work best together IMO, as they're complementary techniques, not competing. If you need shared state, brokers and/or IPC are a poor substitute for the performance of Threads (IME). Plus they're much more complex if you have a robust set of Thread Safe libraries to draw on.
moe 15y ago
If you want to claim it's fast ("screams") then you should provide some benchmarks.
- benporterfield 15y ago
  Not really any better, but there is a simple chart on what appears to be an unfinished version of the website: http://puma.io/ http://puma.io/
  - Omni5cience 15y ago
    I really want to know where they got that lorem ipsum text... Mustache deserunt yr viral. Ut farm-to-table velit ethical put a bird on it officia, qui yr lomo. Nesciunt organic voluptate mcsweeney's, vinyl et skateboard 3 wolf moon mollit dreamcatcher blog.
    - lacerus 15y ago
      http://hipsteripsum.me/?paras=4&type=hipster-latin http://hipsteripsum.me/?paras=4&type=hipster-latin
  - dons 15y ago
    Though even the best result, 650 req/sec is around 100x slower than compiled, current webservers in e.g. Scala or Haskell.
mattgreenrocks 15y ago
Puma uses a thread pool to handle requests. The only other Ruby web servers I know of that do this are Rainbows!, and Zbatery, and they're a bit obscure, unfortunately. Unlike Thin, EventMachine is not used. I have it running on my Heroku instance for a day or so with no issues, though I don't get any traffic yet. :)
- cies 15y ago
  if you need traffic the you forgot to put a url in your post.. :)
  - mattgreenrocks 15y ago
    It's a backend web service, so I think I'll pass. :)
cies 15y ago
i see quite a bit of code from zed shaw's mongrel in there[1].. to the extend that i think puma is simply a mongrel that uses threading. you say it is using ragel; mongrel also uses ragel[2]. mongrel and z.shaw are even mentioned on the ragel project page. (and ragel is mentioned on the mongrel page[3]) sorry but i think puma could be more upfront about being an innovation on top of mongel. otherwise nice work! code looks indeed very clean compared to unicorn/rainbows and zbattery. [1]: https://github.com/evanphx/puma/tree/master/ext/puma_http11 https://github.com/evanphx/puma/tree/master/ext/puma_http11 [2]: http://www.complang.org/ragel/ http://www.complang.org/ragel/ (mentions mongrel) [3]: https://github.com/mongrel/mongrel https://github.com/mongrel/mongrel
- ejfinneran 15y ago
  My understanding based on a presentation from Dr. Nic is that Puma is a straight fork of Mongrel since Mongrel had threading from the beginning but it is essentially unsupported now. This commit lends to that story as well: https://github.com/evanphx/puma/commit/1888887d8ff8fdf4954c3ebf12ef56526735be0d https://github.com/evanphx/puma/commit/1888887d8ff8fdf4954c3... I agree though, would be nice to mention its heritage in the read me.
andrewvc 15y ago
What's missing in the description here is that Puma is built for Rubinius and jRuby, which both have true multithreading (no GIL). I'm not sure if it's considered production ready yet though.
pkieltyka 15y ago
IMO, its a step in the right direction to build threaded concurrency into the foundation of a Ruby web server. Events can be layered within those threads. Then you can even have a nice mix of sync / async code on a single web server running harmoniously. Also, if running just a single thread, we're in the same place as most other Ruby web server, but for those VMs that can take advantage of it, and for those stacks that can benefit, its awesome. I hear you guys in the comments saying events is the way to go for concurrency in Ruby, especially with MRI. As many also know, GIL-less threads are available in modern Ruby VMs like Rubinius and JRuby. I haven't tried puma yet, but I do believe in evanphx's work. Also, for those interested in concurrency with Ruby, also check out: https://github.com/tarcieri/celluloid https://github.com/tarcieri/celluloid and https://github.com/tarcieri/nio4r https://github.com/tarcieri/nio4r .. looks like Tony even has a fork of puma in there too.
Omni5cience 15y ago
I'm just going to add a shout-out to a friend's project which uses Mongrel2 (Zed Shaw's new awesome application, language, and network architecture agnostic web server). https://github.com/ArtemTitoulenko/Angstrom https://github.com/ArtemTitoulenko/Angstrom

37 points by grk 15y ago

This seems like a neat accomplishment, but why would I use it? There is mountains of work for standard configurations including security hardening, monitoring, configuration management, etc. What about this product makes it better than the other options?

mbq 15y ago

tl;dr it parses HTTP headers with Ragel, which is a really nice idea; the state machine part is a yummy bite.

dnc 15y ago
Correct me if I'm wrong, but I don't see how is this different from Thin, AFAIK it also uses Ragel for the same purpose.
- towelrod 15y ago
  thin uses EventMachine and puma uses threads.
- carmen 15y ago
  this is in the parser files in puma: * Copyright (c) 2005 Zed A. Shaw puma's README wording make it seem like the Ragel parser is some new thing unique to Puma, and doesnt mention Zed. no wonder he hatest rubyists also, thin has had a --threaded flag for years
  - mattgreenrocks 15y ago
    Thin's --threaded flag is still considered experimental. Also, spawning a native OS thread per incoming connection is not cheap, either.
    - getsat 15y ago
      At high numbers of concurrent connections, your thread stacks consume a non-trivial amount of ram, too.
zedshaw 15y ago
It is a really nice idea, which is why I used it in Mongrel and now it looks Puma is a fork of Mongrel so I'm doing it again!

juliennakache 15y ago

I'ven't looked at the code base, but I don't get how you're allowing true concurrency without any evented framework?

mitchty 15y ago
The same way every non-evented codebase does. Threads. https://github.com/evanphx/puma/blob/master/lib/puma/thread_pool.rb https://github.com/evanphx/puma/blob/master/lib/puma/thread_...
- juliennakache 15y ago
  Then IMHO it's very unlikely to be "screamin" fast using the MRI
  - ssmoot 15y ago
    So don't use MRI. Events are not a substitute for Threads, and Threads are really not as hard as people would like to claim when you're working at the level of an application developer. Keep in mind that hundreds of thousands (wild guess) .NET developers have worked with both Threads and Events for years in WinForms and WebForms without much trouble. Because 99% of the time as long as you follow a few simple rules about what you're passing to an event, and you use built-in thread-safe collections along with the occasional custom double-lock, you're going to be safe. The framework takes care of most of it for you. Disclaimer: Having little experience with Node.js and some of the other new-ish evented frameworks, the following observation is probably at least somewhat off-base. But it occurred to me the other day that in a lot of ways many OSS projects are trending towards popularizing a model Microsoft mainstreamed (at least in my limited decade-plus experience). ie: "Delegate All The Things!" Wasn't really a fan of it then (there are definitely advantages, but I think you can make the claim it went entirely too far) and I guess that's what left a sour taste in my mouth when anyone brings up Evented programming as some sort of silver bullet. In addition to that, considering my experience with Thread Pooling and Events, it always strikes me as odd when they're presented as competing solutions. They work best together IMO, as they're complementary techniques, not competing. If you need shared state, brokers and/or IPC are a poor substitute for the performance of Threads (IME). Plus they're much more complex if you have a robust set of Thread Safe libraries to draw on.

moe 15y ago

If you want to claim it's fast ("screams") then you should provide some benchmarks.

benporterfield 15y ago
Not really any better, but there is a simple chart on what appears to be an unfinished version of the website: http://puma.io/ http://puma.io/
- Omni5cience 15y ago
  I really want to know where they got that lorem ipsum text... Mustache deserunt yr viral. Ut farm-to-table velit ethical put a bird on it officia, qui yr lomo. Nesciunt organic voluptate mcsweeney's, vinyl et skateboard 3 wolf moon mollit dreamcatcher blog.
  - lacerus 15y ago
    http://hipsteripsum.me/?paras=4&type=hipster-latin http://hipsteripsum.me/?paras=4&type=hipster-latin
- dons 15y ago
  Though even the best result, 650 req/sec is around 100x slower than compiled, current webservers in e.g. Scala or Haskell.

mattgreenrocks 15y ago

Puma uses a thread pool to handle requests. The only other Ruby web servers I know of that do this are Rainbows!, and Zbatery, and they're a bit obscure, unfortunately. Unlike Thin, EventMachine is not used. I have it running on my Heroku instance for a day or so with no issues, though I don't get any traffic yet. :)

cies 15y ago
if you need traffic the you forgot to put a url in your post.. :)
- mattgreenrocks 15y ago
  It's a backend web service, so I think I'll pass. :)

cies 15y ago

i see quite a bit of code from zed shaw's mongrel in there[1].. to the extend that i think puma is simply a mongrel that uses threading. you say it is using ragel; mongrel also uses ragel[2]. mongrel and z.shaw are even mentioned on the ragel project page. (and ragel is mentioned on the mongrel page[3]) sorry but i think puma could be more upfront about being an innovation on top of mongel. otherwise nice work! code looks indeed very clean compared to unicorn/rainbows and zbattery. [1]: https://github.com/evanphx/puma/tree/master/ext/puma_http11 https://github.com/evanphx/puma/tree/master/ext/puma_http11 [2]: http://www.complang.org/ragel/ http://www.complang.org/ragel/ (mentions mongrel) [3]: https://github.com/mongrel/mongrel https://github.com/mongrel/mongrel

ejfinneran 15y ago
My understanding based on a presentation from Dr. Nic is that Puma is a straight fork of Mongrel since Mongrel had threading from the beginning but it is essentially unsupported now. This commit lends to that story as well: https://github.com/evanphx/puma/commit/1888887d8ff8fdf4954c3ebf12ef56526735be0d https://github.com/evanphx/puma/commit/1888887d8ff8fdf4954c3... I agree though, would be nice to mention its heritage in the read me.

andrewvc 15y ago

What's missing in the description here is that Puma is built for Rubinius and jRuby, which both have true multithreading (no GIL). I'm not sure if it's considered production ready yet though.

pkieltyka 15y ago

IMO, its a step in the right direction to build threaded concurrency into the foundation of a Ruby web server. Events can be layered within those threads. Then you can even have a nice mix of sync / async code on a single web server running harmoniously. Also, if running just a single thread, we're in the same place as most other Ruby web server, but for those VMs that can take advantage of it, and for those stacks that can benefit, its awesome. I hear you guys in the comments saying events is the way to go for concurrency in Ruby, especially with MRI. As many also know, GIL-less threads are available in modern Ruby VMs like Rubinius and JRuby. I haven't tried puma yet, but I do believe in evanphx's work. Also, for those interested in concurrency with Ruby, also check out: https://github.com/tarcieri/celluloid https://github.com/tarcieri/celluloid and https://github.com/tarcieri/nio4r https://github.com/tarcieri/nio4r .. looks like Tony even has a fork of puma in there too.

Omni5cience 15y ago

I'm just going to add a shout-out to a friend's project which uses Mongrel2 (Zed Shaw's new awesome application, language, and network architecture agnostic web server). https://github.com/ArtemTitoulenko/Angstrom https://github.com/ArtemTitoulenko/Angstrom