Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Heroku Ruby guy here. I recommend Puma. Especially if your app is threadsafe. Even if it isn't you can still run multiple workers and only one thread and you get protection against slow clients (that Unicorn doesn't have). https://devcenter.heroku.com/articles/deploying-rails-applic...

I also wrote this gem that tunes the number of Puma workers and resets any workers where a memory leak is detected: http://github.com/schneems/puma_auto_tune



I admire your recent work with threads in Ruby with the Puma libraries and the threaded in memory queue (I was working on something similar myself, I keep forgetting to get back to it though). Most companies I see using Heroku are always wondering if their bill could be lower and most of the time they are using preforking servers and background job processors.

I look forward to your talk at Ancient City Ruby next week!


Any idea why the docs[1] recommend using Unicorn instead?

On Cedar, we recommend Unicorn as the webserver. Regardless of the webserver you choose, production apps should always specify the webserver explicitly in the Procfile.

[1]: https://devcenter.heroku.com/articles/ruby-support#rails-4-x...


Wow, this is awesome. You should add a link to the Puma guide [1] as I've been wanting to make use of Puma workers for a while but have always been worried about running out of memory.

[1] https://devcenter.heroku.com/articles/deploying-rails-applic...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: