
Puma: A Ruby Web Server Built For Concurrency - grk
https://github.com/evanphx/puma
======
cies
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> [2]:
<http://www.complang.org/ragel/> (mentions mongrel) [3]:
<https://github.com/mongrel/mongrel>

~~~
ejfinneran
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/1888887d8ff8fdf4954c3...](https://github.com/evanphx/puma/commit/1888887d8ff8fdf4954c3ebf12ef56526735be0d)

I agree though, would be nice to mention its heritage in the read me.

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

~~~
benporterfield
Not really any better, but there is a simple chart on what appears to be an
unfinished version of the website: <http://puma.io/>

~~~
Omni5cience
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
[http://hipsteripsum.me/?paras=4&type=hipster-
latin](http://hipsteripsum.me/?paras=4&type=hipster-latin)

------
pkieltyka
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> and
<https://github.com/tarcieri/nio4r> .. looks like Tony even has a fork of puma
in there too.

------
mattgreenrocks
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
if you need traffic the you forgot to put a url in your post.. :)

~~~
mattgreenrocks
It's a backend web service, so I think I'll pass. :)

------
jarito
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?

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

~~~
mitchty
The same way every non-evented codebase does. Threads.

[https://github.com/evanphx/puma/blob/master/lib/puma/thread_...](https://github.com/evanphx/puma/blob/master/lib/puma/thread_pool.rb)

~~~
juliennakache
Then IMHO it's very unlikely to be "screamin" fast using the MRI

~~~
ssmoot
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.

------
andrewvc
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.

------
Omni5cience
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>

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

~~~
dnc
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.

~~~
carmen
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
Thin's --threaded flag is still considered experimental. Also, spawning a
native OS thread per incoming connection is not cheap, either.

~~~
getsat
At high numbers of concurrent connections, your thread stacks consume a non-
trivial amount of ram, too.

