Use puma

[steveklabnik]

First of all, since I can't get therubyracer to work on my machine, I cannot actually bundle install, so someone else will have to add a commit to this that updates the lock.

Secondly, no matter what we do, we shouldn't have both thin and unicorn in our gemfile, that's stupid.

Third: puma.

Given https://blog.heroku.com/archives/2013/2/16/routing_performance_update/ and some recent research I have done, thin is a bad choice. We're not using resources as well as we could be. Second, unicorn is a bad choice: we want to support development on Windows.

That seems to leave puma. Puma is windows-friendly, mega fast, and has a good concurrency track record.

[steveklabnik]

/cc @carols10cents @wilkie

[jrgifford]

:+1:

[wilkie]

Thin is a perfectly reasonable default. Probably very very good enough for a use-case of "deploy with ease just about anywhere" and very low-moderate usage. (our case?) Maybe put it in the development group. Unicorn in production seems extremely fine. Good for your average job length and moderate to high number of requests. (some of the background tasks may be long... some of our functionality is unreliable...) Puma is fine and certainly the best for servers with short jobs and high requests. But. Is that a typical rstat.us case? I... don't know.

tl;dr -> thin is good for the single-user case. puma is good for the multi-user case. what to do?

Oh my. I dunno. We can argue this forever. :)

[carols10cents]

Is puma inappropriate for development on windows/osx/linux or difficult/inappropriate for deployment in any case? Or is it truly a decent default for all these cases?

I'm not familiar with puma, reading up on it now, but I'm interested in hearing "puma or not-puma" reasons first.

[wilkie]

I've tried it out, and It looks like puma is good for development on windows. It is certainly a better design than thin. I would love an assertion that puma is as easy as thin to deploy. If it is, it is a no-brainer.

[steveklabnik]

There's no difference in deployment. Yay rack!

Puma is written by @evanphx, so I have lots of confidence in it. It's a direct fork of Mongrel, though most of it has been re-written now.

[wilkie]

It's more about how environments support it. I generally think it will be fine. I would really appreciate some assurance that it will deploy easily to lots of different places with absolutely no work. :) I mean, shouldn't we switch to rubinius since that is what Puma prefers/works best with since the argument is that it works better? Will that be a deployment/environment problem? I need more than "it's cool."

[steveklabnik]

Ah.

My more than 'its cool' is that puma will spin up multiple threads, meaning better concurrency per dyno, meaning less $$$ for hosting.

If we wanted additional performance, we could test if it runs on rbx or jruby, turn config.threadsafe! on, and we'd get another boost. But even on MRI, it helps. See this article about Unicorn: http://michaelvanrooijen.com/articles/2011/06/01-more-concurrency-on-a-single-heroku-dyno-with-the-new-celadon-cedar-stack/ We've already determined Unicorn is a no-go, but we'd see something similar.

[carols10cents]

I combined testing this out with writing instructions on deploying your own node and started with heroku, and deploying with puma was exactly the same as deploying with unicorn.

I would love to test out (and write up instructions for) deploying rstat.us to engineyard with jruby and puma as well. I'm betting it'll be similarly straightforward.

What hosts does rubinius play well with? Does rstat.us work well on rbx these days?

[steveklabnik]

I have no idea, as I said, due to therubyracer, I can't even get the site running at the moment. But given that most hosts are just using rvm/rbenv to manage rubies, it should be just fine. Heroku specifically uses the ruby version in your Gemfile to determine which Ruby to run, though it looks like there might be an issue or two.

[veganstraightedge]

For what it's worth, I run all of my Heroku sites locally and in production on Puma with almost zero effort.

Locally, I'm on a Mac. puma -p 3000 == rails server

Remotely, I add this to my Procfile: web: bundle exec puma -p $PORT

And everything Just Works™

I hope y'all have similar ease of use.

[schneems]

One thing to watch out for using Puma with Rails is by default Puma comes with 16 threads, and Rails only comes with 5 database connections in it's pool https://devcenter.heroku.com/articles/concurrency-and-database-connections you can configure fewer threads with puma or more connections in active record. I've got a site running puma and for awhile couldn't figure out why I was getting random DB connection timeouts, this was the culprit.

[carols10cents]

Bad maintainer! Merged this in after letting it sit forevverrrrr :( :heart: