Use puma #740

Merged
merged 2 commits into from May 27, 2013

Conversation

Projects
None yet
6 participants
@steveklabnik
Contributor

steveklabnik commented Feb 16, 2013

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.

use puma.
Using thin and unicorn is silly
@steveklabnik

This comment has been minimized.

Show comment Hide comment
@steveklabnik

steveklabnik Feb 16, 2013

Contributor
Contributor

steveklabnik commented Feb 16, 2013

@jrgifford

This comment has been minimized.

Show comment Hide comment
@jrgifford

jrgifford Feb 16, 2013

Contributor

👍

Contributor

jrgifford commented Feb 16, 2013

👍

@wilkie

This comment has been minimized.

Show comment Hide comment
@wilkie

wilkie Feb 16, 2013

Contributor

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. :)

Contributor

wilkie commented Feb 16, 2013

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

This comment has been minimized.

Show comment Hide comment
@carols10cents

carols10cents Feb 18, 2013

Contributor

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.

Contributor

carols10cents commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@wilkie

wilkie Feb 18, 2013

Contributor

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.

Contributor

wilkie commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@steveklabnik

steveklabnik Feb 18, 2013

Contributor

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.

Contributor

steveklabnik commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@wilkie

wilkie Feb 18, 2013

Contributor

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

Contributor

wilkie commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@steveklabnik

steveklabnik Feb 18, 2013

Contributor

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.

Contributor

steveklabnik commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@carols10cents

carols10cents Feb 18, 2013

Contributor

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?

Contributor

carols10cents commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@steveklabnik

steveklabnik Feb 18, 2013

Contributor

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.

Contributor

steveklabnik commented Feb 18, 2013

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

This comment has been minimized.

Show comment Hide comment
@veganstraightedge

veganstraightedge Feb 26, 2013

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.

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

This comment has been minimized.

Show comment Hide comment
@schneems

schneems Apr 3, 2013

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.

schneems commented Apr 3, 2013

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 carols10cents merged commit be36790 into master May 27, 2013

1 check passed

default The Travis build passed
Details
@carols10cents

This comment has been minimized.

Show comment Hide comment
@carols10cents

carols10cents May 27, 2013

Contributor

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

Contributor

carols10cents commented May 27, 2013

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

@carols10cents carols10cents deleted the use_puma branch May 27, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment