Today I have something special for you. I know programmers love diagramms so I made one about how to tune your Ruby on Rails application if you encounter performance problems.
It won't cover anything I guess, but it should cover some basic questions you have to ask yourself and steps to get your app running smothly. In the diagramm i placed some numbers that point to longer explanations if you need any. Additionally I plan on making special blog posts for some of the numbers to help you out. You can click on the thumbnail above if you want a larger version of the diagramm.
Explanations for the numbers
- Use tools to find out where your bottlenecks are. ruby-prof and new_relic are tools I use to find out where my apps consume to much memory.
- ActiveRecord tends to bloat your Memory by allocating to much objects. Sometimes you don't need that much. Refer to my blog post or to this source to get some help.
- Is your stack exploding because you mess with recursive functions or do you allocate objects that you don't need. Watch out how long you objects live ( ruby-prof ) and tune your garbage collection.
- Key-Value-Stores like redis are very fast and can help you saving memory by reducing the amount of objects that you need to keep there. Serialize and deserialize your objects to a store like this.
- Background Processing can help you when your app-servers are to busy or if requests just do to much things. With an asynchron design and queing you can work off a great bunch of things. Just be careful that you keep your jobs small. I normally use a spawner job that creates a many small jobs that do the work. Go for resque or sidekiq.
- Use a multithreaded server, that your requests can run in parallel. Passenger or Puma can help you out.
- Just look at the awesome rails docs.
- Use rails update_all and delete_all helpers to update or delete a bunch of records with SQL without getting them to memory first. Careful this won't trigger observers.
- A caching-system is optimized for the task. Rails uses a file based cache per default which is way slower than using memcached with dalli for example.
- Slim is faster than Haml if you believe performance benchmarks. ERB is even faster.
- Index servers can help you building better queries and even proper searching. Counting of records is way faster there than in usual RDBMS Systems because they don't use transaction concepts.
- Endless scrolling prevents you from calculating the maximum number of pages, which is a reason for slow pagination for millions of records in RDBMS Systems.
- Pagination with Kaminari or will_paginate.
- Turbolinks or wiselinks make all your pages load faster without much efford. They use ajax queries to beat normal browser loading. You can even implement small parts yourself (for example if you display information from an external slow service like RSS).
- Both SASS and LESS offer you support for bootstrap mixins. If you use them you can implement your views way cleaner and spare load time.
- Try to avoid redundant HTML containers and use a clear HTML markup. This will reduce your CSS and HTML code and will make your pages load faster.
- I can't help you here ... I you find more mail me and I will add this to this image.
- Precompiling assets should be on in production, espacially if you use things like SASS or coffescript.