I just moved Adstaq over to Puma this weekend because I want to experiment with a multithreaded server as a way to keep our web serving costs down and our efficiency high. We're already doing this with Sidekiq for our worker code, to great effect, and philosophically I much prefer plain old Ruby threads over other Ruby concurrency solutions. Dave Copeland gave a GREAT talk at RubyConf last year called Don't Fear the Threads which I highly recommend for further inspiration.
It took some trial and error to get Rails talking to Puma and to get everything running on Heroku, so I put the needed code into a gist, embedded below.
I'm monitoring the change on New Relic but so far have not noticed any memory savings vs. Unicorn. But we're also not drowning in traffic right now. Nonetheless I'm glad we're getting some Rails multithreading experience before that happens.
Update: Watsi posted some great instructions for adjusting ActiveRecord's connection pool size.
Subscribe to:
Post Comments (Atom)
4 comments:
Are you limiting the thread pool per dyno in any way? I believe by default, Puma's range is 0:16, and I've read that 4 is about as many as you'd want running on Heroku.
I'm running 0:16. They don't appear to limit threads, just memory size.
What's with the puma.rb config file? Is that really necessary? I can't find any notice of it on puma's github.
Also, I tried running with a "before_filter { sleep 3 }" and it wasn't handling the requests concurrently. I was under the impression that even with MRI sleep wouldn't block threads.
Did you ever get numbers supporting or refuting puma on heroku?
Post a Comment