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.
Related
Usually, accessing a database tends to be the most costly operation in terms of time.
However, since Ruby is among the slowest executing languages (with rails representing an abstraction built on top of an already existing abstraction), do rails apps tend to perform slower than (or as slowly as) most queries to the db?
This is a really subjective question, but in short, yes, of course it can become more of a bottleneck than the DB, depending on your core business concerns. If, say, the only reason you have a database is to require a login, and therefore only make one call to the users table, but your website is all about image processing and you do lots of computationally expensive stuff, then ruby will be more of a concern to you than the database.
The age old idea that you should pick the right tool for the job will never fail to be true.
I don't have much experience on this topic, as I don't do Rails development any more. However, Aaron "tenderlove" Patterson gave a talk "ZOMG WHY IS THIS CODE SO SLOW?" (slideshare, confreaks video), where he talked about ActiveRecord previously being slow because the Ruby implementation used to be sub-optimal.
Yes.
A stupid but true example will be...
def index
#thing = Thing.find_by_something_not_needed params[:something_not_needed]
unless something_happens do
sleep
end
end
def something_happens; nil; end
Now imagine you were doing some complex logic - such as image processing, or maybe an extraneous stab at the travelling salesman problem with substantial data - that could be modeled by the death loop I have in my silly example. Other factors may be external web requests that just dont go well.
Rails is already the slowest framework among the rest of the 'active' Ruby frameworks (Camping, Sinatra, Merb, Padrino, Ramaze).
I found a recent 'unscientific' benchmark: http://pastie.org/2294509 (benchmark source padrino framework's github repository) that provides some results.
The slowness may not manifestate itself that much in production (It probably shouldnt be the cause of a bottleneck), but you will surely experience it while developing applications: Extremely slow boot times, slow rake tasks, very slow test suites, high memory footprint.
This is a compromise. Rails is feature rich and has been around for a long time with a large, active community.
Unfortunately the situation may not improve as with every new Rails version the framework grows larger, with additional layers of abstraction that affect speed. This is pure speculation on my side, but judging by the user base, we won't see any drastic changes to Rails itself to alleviate these problems. The last game changing version 3 has brought a lot of long sought improvements, but they were more of improvements to the modularity of the framework, rather than improvements to performance.
This question is like asking "Can a Porsche be slowed down to a slower speed than a Pinto?".
You should judge your performance in average millisecond response times. For example, if a page in your app takes on average 100ms to sun, then in theory, you can get 10 request per second. If you investigate and determine that 100ms is because 60ms is being spent parsing some string...a string that can be reduced or even ignored, then the problem really isn't Ruby or Rails is it?
Ruby/Rails is fast enough for most web applications. I think you are trying to convince yourself to use something other than Rails. If you don't want to use Rails, that is fine. But don't abandon Rails because it COULD be slowed down by bad programming. This is true of any language.
Instead, embrace Rails (or Sinatra or Padrino or Django) and have fun. Worry about performance when performance is an issue.
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.
----edit-----
QUICK QUESTION: Does Grails take too much resources for high traffic website, and is it expensier to host?
For example: if I can make a site that has millions of users/m easier in CakePHP does it worth to make it in Grails just to save some webserver resources- or will it need more servers?
---------------
Hello,
I know there are a lot of similar questions on the net, but because I am a newbie in web development I didn't find the solution for my specific problem.
I am planing on creating a flash games portal from scratch. It is a big chance that there will be big traffic from the beginning (millions of pageviews). I want to reduce the server costs as much as possible but in the same time to not be tide to an expensive contract as there is a chance that the project will not be as successfully as I want and in that case the money would be very little.
The question is : what technology to use? I don't know any web dev technology yet so it doesn't matter what I will learn. My web dev experience is a little php 8 years ago, and from then I programmed in C++ / Java- game and mobile development. I like Java and C syntax and language very much and I tend to dislike dynamic typing or non robust scripting (like php)- but I can get along if these are the best
choices.
The candidates are now: -
Grails (my best for now)
Ruby on Rails
Cake PHP
Other technologies (Google App
Engine, Python/Django etc...)
I was considering at first using pure C and compiling the web app in the server- just to squeeze more from the servers, but soon I understand that this is overkill.
Next my eyes came on Ruby - as there is a lot of buzz for it's easiness of use. Next I discovered Grails and looked at Java because it is said that it is "faster". But I don't know what this "Faster" really means on my needs, so here comes the first question:
1) What will be my biggest consumption on the server, other than bandwidth, for a lot of flash content requests? Is it memory? I heard that Java needs a lot of memory, but is faster. Is it CPU? I am planning to take some daily VPS.NET nodes at first, to see if there is a demand, and if the "spike" is permanent to move to a dedicated server (serverloft.com has some good offers), else to remain with less nodes.
I was also considering developing in Google App Engine- cheap or free hosting to use at first - so I can test my assumption- and also very easy to use (no need for sys administration) but the costs became high if used more (> 3 million games played / month .. x mb/ each). And the issue with Google is that it looks me in this technology.
My other concern is scalability (not only for traffic/users, but as adding functionality) My plans are to release a functional site in just 4 weeks (just the basics frontend and some quick basic backend - so I can be able to modify some things and add games manually) - but then to raise it and add more things to it. I am planning to take a little different approach than other portals so I need to write it from scratch (a script will not do).
2) Will Grails take much more resources than RoR or Php server wise? I heard that making it on Java stack will be hardware expensive and is overkill if you don't make a bank application. My application will not be very complex (I hope and i will try to) but will have a lot of traffic.
I also took in account using CDN for files, but the cheapest CDN found was 5c/GB (vps.net) and the cost per gb on serverloft (http://www.serverloft.com/dedizierte-server/server-details.php?products=4) is only 1.79 cents/GB and comes with the other resources either.
I am new to this domain (web). I am learning the ropes and searching on the web for ~half of year but don't have any really practical experience, so I know that I must have some naive thinking and other issues that i don't know from now, so please give me any advice you want regarding anything, not just the specific questions asked.
And thank you so much for such great community!
This is how I (on my blog) view web performance, especially for highly abstracted frameworks like Grails.
I don't understand the obsession with
runtime performance. Given most
project scenarios your primary focus
should be on your performance, as in
your ability to get things done with a
chosen technology.
For example, you will get more done in
a given period of time with Groovy
than with Java any day. Often one line
of Groovy code will equate to 10 lines
of Java code etc etc
Very rarely will byte code execution
time be your performance issue, most
often its...
Bad algorithm implementation or
design. Bad DB design and / or queries.
Taking to long to get things done and
then having all sorts of commercial
relationship issues because of it.
With web applications you are usually
not performing lots of long running
CPU bound operations. Most of your
request / response time is spent in
the wire (internet routing etc) and in
the DB (executing queries).
Choose a technology that takes a load
off your mind and one that frees you
from writing mountains of boiler plate
code, so that you can rather
concentrate on designing and
implementing good algorithms, DB's and
queries etc etc
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.