3 ms·
Until Rails 4, the core framework didn’t even support concurrent request handling. Rails has supported multithreaded operation since 2.2: http://guides.rubyonr
by bascule 13y ago
Until Rails 4, the core framework didn’t even support concurrent request handling.
Rails has supported multithreaded operation since 2.2: http://guides.rubyonrails.org/2_2_release_notes.html http://guides.rubyonrails.org/2_2_release_notes.html
It never gained widespread adoption because it was off by default. Rails 4 turns it on by default on multithreaded web servers like Puma.
And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures.
This isn't true on JRuby, where Ruby threads are 1:1 with JVM threads (which are in turn 1:1 with native threads) that execute in parallel on multiple cores.
At my employer (Square) we run many of our Rails apps in thread safe mode on top of JRuby, providing parallel request processing across multiple cores on a single JRuby/JVM instance.
- kawsper 13y agoHow is the state of the thread-safety among gems? I have thought a lot about it, but the danger of having thread-issues in the included gems are a bit daunting to be honest.
- bascule 13y agoNot as great as some other language ecosystems, however many people are using Sidekiq, a multithreaded job queue, successfully (and more generally, the Celluloid concurrency framework Sidekiq is based on)
- VLM 13y agoThis meme is identical to the trashing mysql gets in 2013 because it doesn't have transactions. I'm sure when rails 50 ships people will still be claiming it can't multithread.
- el_bhs 13y agoJRuby is of course incompatible with C extensions to Rails; the place I used Rails had such dependencies, and so JRuby was not an option. I agree that JRuby is otherwise preferable to cRuby, though. I'd be curious to hear how Square has found ruby (independent of rails) to be from a maintenance standpoint.
- erikpukinskis 13y agoI assume this wasn't an option for you, but you can sometimes get around this limitation by doing any C-dependent work in a job queue.
- dragonwriter 13y ago> JRuby is of course incompatible with C extensions to Rails The fact that old-style native extensions are tied to MRI is one of the motivations for Ruby FFI, which provides a common mechanism for interfacing to native libraries on MRI, JRuby, and Rubinius (and maybe some other implementations, as well.)
- bascule 13y agoCheck out Xavier Shay's talk on JRuby at Square for more info on our experiences: https://www.youtube.com/watch?v=hMpd4CzR1f8 https://www.youtube.com/watch?v=hMpd4CzR1f8
- josevalim 13y ago> And even in Rails 4, concurrent request handling is multiplexed on a single CPU Actually, even on YARV you will use more than one CPU, however the GVL won't allow them to be used efficiently. My point is: there is nothing in Rails forcing it being multiplexed into a single CPU, it is all about which language implementation and web server you choose. The post is also very inconsistent on its own arguments. If multi-core and being able to share memory in between cores is a criteria, Node is also not a good option compared to what you have in the JVM, Erlang VM, Haskell, Go, etc.