Ruby Garbage Collection: Still Not Ready for Production

Re:Ruby Garbage Collection: Still Not Ready for Production by thinkbohemian on Friday March 28, 2014 @01:05PM (#7488492)

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

[ Parent | on HN ]

Re:Ruby Garbage Collection: Still Not Ready for Production by rubiquity on Friday March 28, 2014 @01:16PM (#7488564)

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!

[ Parent | on HN ]

Re:Ruby Garbage Collection: Still Not Ready for Production by wasd on Friday March 28, 2014 @04:36PM (#7489809)

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

[ Parent | on HN ]

Re:Ruby Garbage Collection: Still Not Ready for Production by jamesharker on Friday March 28, 2014 @02:49PM (#7489199)

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

[ Parent | on HN ]