Note: Ruby On Rails Performance Apocrypha [Principle]

This is a study note for the book Ruby On Rails Performance Apocrypha by Nate Berkopec. This book shows some guidelines and practical methods to solve performance issues with ROR. It is a good book to grasp so the idea for who does not familiar with this issue.

This book contains the different part, this post will mainly cover the Principle part.

Why Performance?

There must be a reason for you want to make the performance better. Different target leads to a different solution, so it is important to know it before starting your work. Generally, the reason should be sitting with the following three:

1. Improve the customer experience

• This usually covers both the frontend and the backend. And usually, the frontend consumes more time than the backend.

2. Decrease the operational costs

• This means to reduce the average latency of requests.
• The frontend is irrelative here because you don’t pay for the time client spent.

3. Prevent outages caused by traffic increases

• About how to manage the utilization of your capacity and how easy and fast to add more capacity.

Processing Step

1. Observation: Find the problem with APM tools such as New Relic or Scout
2. Hypothesis: Use Profiler to figure out the root of the problem
3. Test: Run with Benchmarking to see how it work
4. Analyze: Observe again after deploying it in production

• Profiling: monitor every behavior with a lot of overhead which make code a lot slower
• Benchmark: test without overhead, more like the real world

Possible Problem Area

When trying to solve the performance issue, look down these areas in order:

1. Database & ActiveRecord: with rack-mini-profiler
2. Ruby: with stackprof or ruby-prof
3. Memory: Focus on garbage creation rather than garbage collection. Creating objects is expensive

Extra: Sometimes the problem may come from inappropriate design. For example, instead of optimizing the speed of a page that loading 100 blog posts, implementing pagination will be much easier.

Cache

Cache is a good solution to make a page faster by pre-computing and pass the saved result. It can be a part of HTML, a complete web response, or a SQL query.

But cache is not the holy grail for every problem:

1. Adding cache means adding a new service to the app, indicating more cost and increase the difficulty to maintain.
2. Should consider the cache hit rate. The higher the hit rate, the higher the re-used rate of the stored result. If the hit rate is under 50%, cache may even make the code slower. Ideally, it should higher than 95%.