4 ms·
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 ge
by thinkbohemian 13y ago
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-applications-with-the-puma-web-server 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 http://github.com/schneems/puma_auto_tune
- rubiquity 13y agoI 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!
- jamesharker 13y agoWow, 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-applications-with-the-puma-web-server https://devcenter.heroku.com/articles/deploying-rails-applic...
- wasd 13y agoAny 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-applications https://devcenter.heroku.com/articles/ruby-support#rails-4-x...