4 ms·
I got to beta this inside of Heroku (I work there), using the memory stats I was able to safely go from 3 Unicorn workers on http://www.codetriage.com/ http://w
by thinkbohemian 14y ago
I got to beta this inside of Heroku (I work there), using the memory stats I was able to safely go from 3 Unicorn workers on http://www.codetriage.com/ http://www.codetriage.com/ to 8. Concurrency++
- thinkbohemian 14y agoUpdate: due to the traffic I'm seeing different memory patterns and now it's running at 7 workers. Always monitor in production after running benchmarks :)
- nixme 14y agoIf your app is thread-safe and mostly I/O bound, try the puma[1] 2.0 beta releases. You can cluster processes like Unicorn, but also run multiple request threads in each process for maximum concurrency. Don't forget `config.threadsafe!` to remove Rack::Lock and fixup class loading. [1] http://puma.io/ http://puma.io/
- thinkbohemian 14y agoI've used and enjoyed Puma before. If you want you can run this app on Puma https://github.com/codetriage/codetriage https://github.com/codetriage/codetriage I've even run this app on JRuby on Puma on Heroku (worked well). Currently my interests are in Unicorn config and settings on MRI though.
- nixme 14y agoCodetriage looks like an awesome idea. Just signed up. I also meant on MRI since the GVL exception for I/O works good enough for most web app requests. If you can fit 7 Unicorn workers on a dyno, I bet you could run 6 puma workers each with 2-4 threads instead and get better results. But YMMV. Though Unicorn's backlog tuning is nice.