Performance measurement basics
Before you can start with this tool, you should know the basics of performance measurement of web applications.
A performance metric is a way to measure the performance of your application. The result, usually a number, can be used to describe the current performance of your application, or the performance improvement in comparison with a previous result.
Performance metrics are usually based on multiple requests (and especially when using request-log-analyzer). Taking only a single request into account is not very useful, because the duration of a request can vary greatly and it does not take the frequency into account.
For Rails applications, it makes sense to look at groups of requests that are handled by a certain action. Every request that is handled by the same action usually has a similar performance, because the same code is executed, similar queries are executed.
- Requests per second is the amount of requests that can be handled within a second. The bigger this number is, the better. It is the most well-known performance metric for web applications, but it isn’t without criticism .
- Average server time is the average time that the server needs to handle a request. This duration is what the visitor has to wait for and determines the user experience. The lower this number is, the better.
- Cumulative server time is the sum of all the server time that was needed to handle all requests for a given group (action). This is what your server “feels”, or is similar to the load on your server. This measurement takes the relative popularity of an action into account. Again, the lower this number is, the better.
- Client time is a metric that takes into account how long it takes to execute the action, but also other factors that impact the performance in the browser, like downloading images, executing javascript, latency, etc. This is an even better performance metric for user experience. As log files are generated on the server, this information is not available to request-log-analyzer and this metric cannot be used.
The reports of request-log-analyzer include average server time and cumulative server time, but also some other metrics like database time and rending time.
After you have detected what actions or code is slow, there are several techniques to improve the performance.
- Only calculate what you need! You will be surprised by the stuff that is being calculated without being necessary if you look closely what is going on.
- Caching: store intermediate results in memory so they do not have to be calculated or evaluated again. More information: Railscast / Rails caching tutorial
- Eager loading: load more objects from the database at once with a single query. More info
- Algorithm analysis and improvement: using smarter or faster algorithms for your calculations.
These are just some techniques than can be used. The best solution always depends on the situation.
Besides analyzing log files, several other useful tools exists to measure and improve the performance of your application. Please contact me if you are aware of other performance analysis tools.
Profiling is a technique to analyze how much time your code needs to run, by measuring the time of every statement. It can also be used to measure memory usage. This technique delivers very detailed results so you know exactly what code is slow and can be improved. Its downsides are that it is very slow to run a profiler and it cannot be used in production mode. You can use request-log-analyzer to see what actions are slow and use profiling to analyze that action in more detail. Ruby-prof is a profiling tool for Ruby/Rails.
Most web applications communicate with a database using SQL queries. Some SQL queries can be very slow to execute. Some of these queries can be significantly faster by using indices. Query reviewer is a Rails plugin that analyses how SQL queries that are executed and gives advise on setting indices that can speed up these queries.