Would it make a difference versus the single core into terms of performance in Ruby on rails app
and if i have multi-core how i manage rails through multi-core
if multi-core processor same idea of distributed servers
Basically, you specify that your rails app run "8 processes" at once and each will use one core. The way I do it is by using phusion passenger [in my case, with nginx] and you may get it to work like
passenger_max_pool_size 8
passenger_max_instances_per_app 8
If you want to make sure your cores are all busy [and have enough RAM] then possibly set them to size 16'ish
Multicore servers only boost performance if the rails app is running in multithreaded mode of in multiprocess mode. Ruby currently supports 'green' threads, which are lightweight and not true processor threads. Rails has support for multithreading, but gem support could be lacking and would probably be unstable for production. To make the best use of a multicore server, running a web server like unicorn or passenger, which can spawn rails processes per core, would provide you the best performance boost
Related
If we say Node.js is single threaded and therefore there is just one thread that handles all the requests, what is Rails?
As I understand, Node.js is both the application and the server, but I am lost on what Rails would be? How does Rails handle requests in terms of threads/processes?
Rails can be single-threaded, it can be multi-threaded, it can be multi-process (where each process is single-threaded), or it can be multi-process where each process is multi-threaded.
It really all depends upon the app server you're using, and it kind of depends upon which Ruby implementation you're using. MRI Ruby supports native threads as of 1.9, but it still maintains what's known as a global interpreter lock. The GIL prevents the Ruby interpreter from running in multiple threads at a time. In most cases that's not really a big deal though, because the thing threads are helping with the most is waiting for I/O. If you're using either JRuby or Rubinius, they can actually run Ruby code in multiple threads at a time.
Check out the different app servers and what they offer in terms of concurrency features. Unicorn is a common one for deploying multi-process/single-threaded applications. Puma is a newer app server that's capable of running multi-threaded applications, and I believe they're either adding (or maybe have added by now, I'm not sure) the ability to run multi-process as well. Passenger seems to be able to work in every model I've listed above.
I hope this helps a little. It should at least give you some things to Google for to find more information.
I am new to Ruby on Rails and beginning a project soon. Having read about different Ruby implementations, I am wondering which setup to use. My project is expected to have a fair amount of traffic.
I am considering two optiosn: MRI Ruby (v 2.0) and JRuby (v 1.9). I am concerned that MRI Ruby is not multithreaded and am worried about the impact this will have on the web app. Perhaps the application server can eliminate this problem? Right now it looks like we will be using Puma as the application server.
In short, should I use JRuby because it is multithreaded on 1.9 or should I use MRI Ruby on 2.0?
TL;DR
Using either Puma or Passenger negates this issue because they handle threads on their own. I would recommend working with the newest version of Ruby and Rails possible as this will minimize the upgrade work you need to do when upgrading your app.
Here is a wonderful article which addresses your issue.
To summarize.
Puma is multithreaded-only. The open source variant of Phusion
Passenger is multi-process single-threaded. The Enterprise variant can
be configured to be either single-threaded or multithreaded.
...
Both Puma and Phusion Passenger Enterprise can be hybrid multi-process
multi-threaded. That is, running multiple multithreaded processes.
Hybrid mode allows Ruby and Python, which despite having a Global
Interpreter Lock, to fully utilize all CPU cores.[1] In Puma, the
hybrid mode is called "clustered".
[1] Only the case on MRI, not on JRuby and Rubinius. JRuby and Rubinius fully support multi-core threads in a single process.
In other words, both Puma and Passenger are able to treat any Ruby implementation as multi threaded. They do this by using a hybrid between multiple processes and multiple threads. This is only minimally heavier than simple multi-threading.
To be honest, I don't think this is an issue you need to worry about at this time. Wait to see how your server handles the site's traffic.
Honestly, if you are new to Ruby and Rails, just stick with the defaults - MRI in this case. Ruby enjoy several great implementations (MRI, JRuby, Rubinius, ...) that will run your web application without any problem. Starts with MRI, you can always decide to change later if needed.
You will be in a much better position to judge what is the best Ruby implementation and server when the work on your application will have started - more proficient on the plateform, and more aware of your specific challenges (not every application is that dependent on multi threading performance).
Enjoy the road!
I have a deployment using:
rails 2.3.2
ruby 1.8.7
mysql db
and
3 mongrel instances (windows services) with apache as load balancer
[I know it is due for upgrade...]
OS: Windows2003
We have many CPU intensive tasks and when these occur on the 4 core machine the mongrel process is able to only use a max 25% cpu power on the core the task was scheduled.
After running many tests we noticed that it is only able to use the power of a single core and therefore there is time lag in finishing tasks.
There is a suggestion to virtualize... which is difficult to do on the client server.
Has anyone got any suggestion on how the situation can be improved? Memory does reach 250MB to 1GB for this process but this not such a big issue.
Thanks in advance
Linus
The typically used Ruby versions (MRI or YARV, i.e 1.8 or 1.9) are not able to use more than one core at a time. MRI is single-threaded and just provides green threads internally. YARV uses real OS threads but has a GIL (global interpreter lock) that ensures that only one thread is running at a time.
Thus, your mongrels are unable to use more than one core each (even if you would have coded your Rails app to be threadsafe). There are alternative Ruby implementations, like JRuby or Rubinius that provide native threads without a global interpreter lock and thus allow your app to use more than one core, but you'd probably need to adapt your app a bit.
That said, even then a single request would run in a single thread and thus only use a single core. But that is something that is hard to come by without you handling your own threads (or at least fibers in 1.9) which is most probably not worth the hassle.
So generally, the recommendation is to start multiple app server processes (mongrels in your case). I personally use about 1.5 - 3 per core (depending on the app). That way, you are able to answer that many parallel requests and fully use your available CPU power shared between them.
I've been using Ruby Enterprise Edition and Passenger (for Apache, since I run Apache anyway for other things) for some time, but I'm wondering if there's a new trend about what to use on servers nowadays.
For example I've heard about Thin, Unicorn... I also know that 1.9.2 is faster than REE, but I wonder about RAM consumption. I'd rather have it consume less RAM even at the expense of some speed.
Thanks for all advice.
If you want minimal memory you should try Thin.
It does not have master worker as Unicorn or Passenger, thus uses less memory.
Suppose you have a very small app that needs to run on a small VM, then you can use 1 thin worker + nginx. I ran several rails 3.2 apps using Thin+nginx+postgres on 256MB VMs without swapping.
Unicorn is faster but it needs a master worker. It's good if you want to run on Heroku, you can set it 2 or 3 workers and be within the 512MB limit.
If your app is very big and you have too many long running requests, I would check out jRuby and Thinidad/Torquebox.
I converted a few apps from MRI+Sidekiq to jruby+Trinidad+Trinidad_Scheduler. I get about 100-200 req/sec using a pool of 50 threads in a trinidad server!
What I like about jRuby is that you can combine everything on one Rails Server. You can put together on the same JavaVM the cache_store with EHcache, Scheduling, Background processing and real multithreading.
You don't need to run redis, memcached, resque or sidekiq separately.
Im not saying they are not good, I love sidekiq and resque, but you can decrease your complexity by combining everything on one process and have high concurrency.
A more advanced and Enterprise solution is Torquebox, it has support for clustering and is super scalable. But I've had problems with my app crashing on torquebox, so i'm sticking to Trinidad for now.
The disadvantages of jRuby? MEmory! A Trinidad server will use minimum 512MB, up to 2-3GB ram.
Also, for Single Thread server, a single request from a rails app running Ruby-1.9.3 is about twice as fast as the same request on jRuby.
Another option is Puma, you can get full multithreading on MRI with puma. I myself could not get it stable enough on my apps.
So, it all depends on your requirements, memory usage, full threading and concurrency.
Apart from Passenger, have a look at Unicorn, Trinidad, Puma and Torquebox. Those seems to be the top rails servers right now.
There is an great book with an introduction of converting your Rails app to jRuby and deploy your app using several methods such as trinidad.
http://pragprog.com/book/jkdepj/deploying-with-jruby
The Torquebox Documentation is amazingly good. It's very detailed and explains really good how to use all Torquebox features.
http://torquebox.org/documentation/
I Hope that sharing my experience has helped.
Passenger is still extremely strong, especially being REE will naturally support 1.9 in the near future. The fact that your application can crash, however it won't affect anything else on your machine is an amazing feature to have. Deploying code is extremely easy because the server will continue to accept connections, which means less frustration/stress for you.
However, in terms of comparisons:
Here is a great resource is check out various comparisons(including memory consumption) with all the new servers.
It compares Thin, Unicorn, Passenger, TorqueBox, Glassfish, and Trinidad:
http://torquebox.org/news/2011/03/14/benchmarking-torquebox-round2/
Mike Lewis' link does a good job of comparing those different ruby servers. My personal experience has been with nginx/REE/Passenger and its been good. I haven't tried the others, so I can't comment on that.
However, I can speak on RAM usage. Your biggest savings of RAM will come from using 32-bit servers. In my experience (3x 3GB app servers), 64-bit REE/passenger processes took up to 2x as much RAM as their 32-bit counterparts. We saw a significant performance increase moving from 64 to 32 bit servers, everything else staying the same. Unless your application requires 64-bit, I would suggest running your application servers (not database) in 32-bit.
Passenger is still a very good choice to use so you are not behind the times or anything. It is also actively supported and has a very good development team that contributes a lot to the community. We have been using Unicorn and it has been very good. Our favorite functionality is to be able to upgrade apps/ruby/nginx without dropping a connection.
I have a Ruby on Rails application that will be a CMS in way which means it's mostly DB intensive. I expect it to have decent amount of traffic so before designing I'm choosing what servers to use. Most important for me is performance.
I heard good things about Nginx and many developers in the Rails community recommends it my only concern about it was that its version is 0.8 which is Beta I believe so I was concerned about potential problems. What is your say?
Also, I want to decide between using Mongrel cluster or Phusion Passenger. What do you think?
I'm planning to user Ruby 1.9 as it has better performance that Ruby 1.8 and I will be using VPS to host my website.
My main things is performance even if it takes longer to setup one over the other.
Your opinion is highly appreciated.
Thanks,
Tam
I'd second for Passenger + Nginx. Very low memory and it's not too difficult to setup. What type of server are your deploying too? Specs? OS? I'd take that into consideration as well considering your available hardware. If you've got enough memory already, then it shouldn't be an issue whether its Passenger or Apache, just optimize and cache your app efficiently.
Two comments:
You can deploy any rails app to any of your mentioned servers, so no need to decide this once and for all now.
IMO mongrel clusters are no longer worth the trouble. Go for passenger on whatever server makes you happy.
Id recommend passenger nginx, the configs are nice and tidy plus the memory footprint is really low compared to passenger apache.