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

Here's a discussion about that point in the original article's comments: http://news.ycombinator.com/item?id=5216553

The conclusion is that it will buy you a bit more time, but does not fix the underlying issue.

In Rap Genius' case, they're large enough that they would still have significant issues even if they switched to cedar and unicorn with 2-4 worker processes.



> they would still have significant issues even if they switched to cedar and unicorn with 2-4 worker processes.

Yeah, but how about config.threadsafe! with puma or thin in multi-thread mode?

It is odd to me that very little of this conversation on the nets recognizes that Rails _does_ support multi-threaded concurrent request handler, with the right app server stack (figuring out the right app server stack can be non-trivial, although it's getting better).


Agreed. I am working with a client who is slightly lower on the Heroku customer food chain and using Unicorn with four workers right now. Our next step is Puma though that will likely not be the end point.


Certainly investigate Puma on Rubinius or JRuby, and make sure you have config.threadsafe! turned on.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: