I made some searches on Google, and I read some posts, articles and benchmarks about Ruby on Rails being slow and I am planning to build one website that will have a good amount of users inserting data and there will be some applications to process this data (maybe in Ruby, you can help me choosing the language).
What is the real performance of Ruby on Rails with large traffic ?
Thank you !
You are asking a lot of questions, so I'll just try to answer you're first one. It is true that ruby, as a language, is slower compared to some others. This means that rails may not perform as well as some other frameworks. However, most websites will not receive the sort of traffic that poses a problem. The productivity gained by using rails most definitely outweighs the potential performance issues you may have later.
Dynamic web pages are slower than static, in general. Scale and performance are more about good design and caching than language choice.
Related
I need to develop an e-commerce site for my client.
He wants it to be very fast (1.25 second or less for each page).
I've had my criterion - 3 seconds.
So 1.25 second is very challenging.
He showed me a website that loads very fast.
http://www.papayaclothing.com/shop/
It's impressive.
I will develop with Spree e-commerce solution (Ruby on Rails).
However, I don't think Ruby on Rails can perform that fast.
Any advice for me?
Thanks.
Sam
Because this is a vast subject, this answer is a community wiki, feel free to improve this answer
Website loading speed depends of many factor : language, framework, DB, CPU, RAM, caching, ...
By the way, the whole thing depends of the worse element. I don't think that Ruby or Rails are the limiting factors here.
To start you can see if Spree is a good framework. Here is a benchmark of Spree in different hosting and comparing to a pure Rails app : http://blog.endpoint.com/2011/05/spree-performance-benchmarking.html
As you can see, this go from 0.5s to 6s ! You can notice that Spree version inpacts a lot on performance. Unfortunately last versions are not on the benchmark... You should try to find an up to date benchmark. You can also notice that a raw rails app is, at first sight, faster.
Next you have to review your hardware : what is your server ? Dedicated or not ? How many CPU and RAM ? Can you increase ?
I think DB is also a thing to watch for a e-commerce case, because I can imagine you have a lot of products. So you can test different DB engines, and see in Spree community what is the recommended one.
Next you can interest you in caching : http://guides.rubyonrails.org/caching_with_rails.html
To go further you can try some memcached store for your putting your cache in RAM : http://guides.rubyonrails.org/caching_with_rails.html#activesupport-cache-memcachestore
Find slowest actions (New Relic is great and their RPM Lite is free though it only reports over last 30 min) and analyze to see if they are render-heavy or db-heavy. My guess would be that your case is db-heavy.
If that's the case, then optimize your queries with eager loading eliminating n+1 problems as well as making sure that only relevant data is returned, e.g. don't do User.all if you only need username and email.
Then you should cache whatever you can, e.g. where real-time data is not crucial.
For more info: http://asciicasts.com/episodes/202-active-record-queries-in-rails-3
and
http://synaptify.com/?p=106
You have a few options here, mentioned in the previous answers.
For client side performance improvements, I'd highly recommend WebPagetest, YSlow, and Yahoo's Best Practices for Speeding Up Your Web Site as good resources.
For strictly Rails performance, I'd suggest Rails' docs on caching (already suggested). I frequently use Rails low level caching. Full page caching can apply to some types of pages, but typically do not work for product pages if you have inventory that fluctuates a lot.
Spree has some performance issues because it is a generic ecommerce solution with many features that you may not use that add bloat. Make sure you have database indexes and consider pursuing profiling server processes to see what's run the most & takes the most time. It's highly probably that you will need to override some of Spree's functionality to speed things up.
Finally, Google considers 0.25 seconds to be the standard for a speedy website.
I've been playing around with Rails (version 3) for a few months now and I understand the framework fairly well. However, I have yet to develop a large website which offers lots of database access and user interaction.
I'm fairly skeptical of the following:
The Speed and Scalability of Ruby (I've heard that its up to 10 times slower than most other server-side languages).
The extra background processing that Rails as a framework (multiple levels of abstration).
The lack of enterprise-level web apps that run on Rails (the only ones that I can think of Groupon, Github and Hulu).
The complexity of the environment (nginx > mongrel > rails > ruby > website).
The behind-the-scenes SQL operations (I know that these can be optimized, but I'm sure that I'll miss some).
For these reasons, I'm unsure whether to continue using Rails or to switch to something that is built ontop a more performant language .. say Java Spring.
Please advise :)
There are tons of large sites and infrastructures in production that use Rails. This question has also been asked to death over the years of Rails being actively used for all manner of web apps, large and small.
Short version is that it is not the fastest language around but despite that scales fine if you know what you are doing. And you should have enough money to hire people that know what they are doing if you actually have any problems of scale.
Scaling any webapp is hard, use the language/framework you know. Programmer happiness is king.
You can get good performance with Ruby. Easy:
require 'inline'
inline :C do |builder|
builder.c <<-C_CODE
void run() {
// Write your entire application in C here
}
C_CODE
end
run
Problem solved ;)
Not the speed and scaling discussion again?
In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.
While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.
The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.
Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?
If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.
And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.
I'm looking for tools to monitor/test performance in rails, and I'm not having much luck finding anything particularly effective. I've read the rails 'performance' guide, but I use RSpec instead of Rake:Test, so I'm not particularly keen to use the rake:test framework.
So, what do folks use for performance testing in rails apart from the rake:test benchmarker? Any suggestions appreciated
Performance benchmarking is one of those things that you'll get different opinions about depending on who you ask. One thing I hear over and over is that you shouldn't obsess over performance early on. I'm not sure where you're at with your application, but this could be something to consider. After developing a rather large application, I can honestly say I agree with them. It's better to use good practice when developing and wait to do performance tuning at a later time. Best practices include things like indexing database columns.
For performance monitoring of live Rails applications, New Relic is one of the best tools out there*. The free plan is a little limited as it only provides 30 minutes of historical data, but the information it collects is priceless. Some of the cloud hosts like Heroku and Engine Yard are offering free bronze plan upgrades, which stores a week of data. Once you have information about your application, you can make educated decisions about where to focus your time.
* My opinion
When your app needs some performance testing, the default TestUnit based performance benchmarking tests are a great start. However, you shouldn't stop there, and should consider using a variety of tools based on the nature of your application.
For example, analyzing production logs using a tool like the request-log-analyzer is a great way to identify the real performance bottlenecks. Bullet is another great tool you can run in your development environment to identify performance inefficiencies in your database calls. For low level benchmarking, rails also gives you the benchmark helper methods in models, controllers and views. This can be handy if you are focusing on tuning some specific part of your application.
It is also worth noting that rspec is not the best tool for benchmarking performance (to date). In my opinion, trying to assert things like it should_take_less_than 50 is stretching the idea of performance testing and trying to force it into the concept of BDD. Performance is less often about absolute expectations and more about identifying the slowest parts of your app and making them faster.
There are many online resources on the topic. I've found these railscasts to be a great starting point:
http://railscasts.com/episodes/368-miniprofiler (free)
http://railscasts.com/episodes/411-performance-testing (pro, requires subscription)
I have some (I think) really great ideas for an online strategy game similar to Travian. There's some content that I haven't yet figured out and some other challenges that I don't know of yet.
This is quite a big project and perhaps too heavy for one person that isn't a skilled web developer (yet). I'd still like to give it a shot, but I'm having trouble choosing a platform. The world "scales" has been thrown around a lot lately and I've seen Ruby on Rails being bashed because it doesn't scale well, so I've come here to get some answers.
I like Ruby on Rails, both Ruby and Rails. I'm certainly no expert at it but I love working with it. I have also worked with Python + Django before and also with PHP (which I am not fond of.)
Ideally the game would have, let's say, 7000 players per server, presumably a lot of data to be processed per second. Would RoR still be a viable platform?
I'm sorry if this question is vague, I guess I'm looking for a "RoR is fine, go at it!" kind of answer. Anything you might want to add is fine.
Thanks!
So if I were you, I would be looking into non-blocking servers like node.js, just because they are MUCH more suited to keeping many connections open for long periods of time, which is what games need to do, compared to traditional web servers.
That being said
There are 3 main things to worry about when you are scaling a web app; memory, execution speed, and io (hd and network) in that order.
For memory, things are much better then they used to be. Phusion Passenger uses copy on write to fork its workers, so the rails environment will get shared among all the workers on a given slice, which is pretty significant. There have also been huge improvements to the way ruby manages memory compared to "the dark times", if you are using 1.8.7 then you want to be using the patches that make up Ruby Enterprise Edition (the difference is like night and day). 1.9.x was pretty much a total rewrite of the runtime, so if you are using that the memory issues ruby had have already been addressed.
For execution speed, 1.8.7 is typically "fast enough" (at least after tuning garbage collection settings). 1.9.2 is actually around the same speed as python, which puts it on the faster side of interpreted languages. How important this point is completely depends on the nature of your application.
Last point is IO, which isn't really a concern of rails, but more your persistence strategy. Rubyists tend to love new things, so you will find first class support for things like redis and mongodb, with loads of people talking about using them and their wins/gotchas. I would look into mongo if I were you and see if the durability trade-offs are acceptable.
I was in java/.net before going to rails, and at the end of the day you are going to pay more for infrastructure, but the amount will be completely dwarfed by what you save in development time.
build it in Rails, host it on Heroku.com - job done. Almost infinite scaling that you don't have to worry about how it works (it just does) and it hosts a lot of highly trafficked Facebook apps so can more than handle it.
I think Ruby on Rails is a good choice for what you need. Actually, we recently created a platform for an online gaming tournament, where players and their gaming bots were playing a logic game.
We used Ruby on Rails and Sidekiq on the backend, ReactJS and WebSocket on the frontend. And it worked well for a quite massive number of players. Here is the tutorial based on what we learnt while building it: How to Write a Game Engine Using Ruby on Rails
As you said yourself, you already have the answer and you are only looking for encouraging words:). I am not RoR expert myself, but I don't think scalability is still such a great issue on this platform. I would advice you to do an architecture spike (XP terminology). Write a test with 7000 clients and method which would perform similar operations to what you intend to create. For example you might load files, render views or even just wait... The point is to test only the thing you are worried about. Good luck!
This is a bit of an impossible question to answer because in order to know whether rails is suitable for what you want to do we would need to a lot more about what you are trying to do. The best advice I can give in the absence of information is for you to check out the railslab scaling videos in order to work it out for yourself.
I have to run a Web server with many services on an embedded server with limited RAM (1 GB, no swap). There will be a maximum of 100 users. I will have services such as a forum, little games (javascript or flash), etc.
My team knows Ruby on Rails very well, but I am a bit worried about Rails' memory usage. I really do not want to start a troll here, but I am wondering if there are any serious (i.e. documented) benchmarks comparing Rails, Django, CakePHP or any other PHP framework?
Could you please point to benchmarks or give me your opinion about Rails' memory usage? Please please please no troll.
In terms of memory usage it's generally going to be Python > Ruby > PHP, which of course leads to Django > Rails > CakePHP. Not just memory but that also tends to hold for raw performance. EDIT: Also worth noting that there are, of course, no absolutes here. There are plenty of usage scenarios in which Ruby will beat Python, hands down. I think we can all agree that Ruby and Python will always beat PHP, though :)
Here's a straight-forward 3-way benchmarking (with Symfony on the PHP side of things) that bears out the above: http://wiki.rubyonrails.com/rails/pages/Framework+Performance. Though of course it's easy to find stats to support your own viewpoint :)
That said, it's still very easy to make a crappy, slow, and inefficient Django application and a lean, fast, and efficient Rails application, or vice-versa. Skill, knowledge, and expertise with the system you are using will do far more for its memory and performance footprint than just the framework itself. Database optimizations, server choices and architectures (Apache vs. proxy setups using nginx/lighttpd, etc.), and fundamental design decisions are likely going to overwhelm the framework's inherent characteristics pretty quickly.
So I guess what I'm saying is if your team knows Rails, and your expertise lies in Rails, I would stick with Rails.
I just stumbled upon this benchmark which looks pretty good. It just gives data about Rails' memory usage (and performance) but it only partially answers the question because it does not compare Rails with other frameworks.
http://www.rubyenterpriseedition.com/comparisons.html
My own experience is that Rails memory usage can be high, especially on 64 bit machines (min. is around 95-100 MB with thin as web front-end). PHP tends to be used with different patterns so it is a bit difficult to compare directly.