Hacker News Reader

Comment by khaless | Hacker News Reader

I'll hook something together this weekend in terms of a benchmark. The nice thing with JRuby is you get the concurrency features of the runtime.

View on HN

try dyno-blitzer https://github.com/pcapr/dyno-blitzer which scales up dynos, runs a load test and tells you how many dynos you'll need to support x concurrent users.

a lot of ruby code isn't threadsafe. I'm pretty sure rails isn't.

Rails is threadsafe if you turn it on by uncommenting config.threadsafe! in your environment initializer.

That's not what I mean. That will make it run with concurrent threads per request. However, I'm fairly certain it isn't threadsafe.

Somewhere around 3.0.6 I made a simple jruby rails app and a sinatra app. They were both a thin REST layer over data in mongodb (No AR). I did load testing and the sinatra app ran fine, the rails app would fail on about 7% of requests with seemingly random stack traces. When I reran the tests with config.threadsafe! turned OFF it never failed.

Also, on Bob Lee's OSCON talk he mentioned some unthreadsafe code in AR that he found.

http://www.oscon.com/oscon2011/public/schedule/detail/21092

I've had good experiences with several jruby on rails apps under tomcat using warbler and they all seem to perform fine with config.threadsafe! enabled. You should probably investigate those stacktraces, maybe they were caused by unthreadsafe gems or application code?

It would fail without using any gems other than trinidad. I'll try to reproduce it tomorrow.

I'm rerunning it now with the latest rails and latest jruby and all is good.

Reply on news.ycombinator.com