Ruby on Rails metrics measuring

Ruby on Rails metrics measuring
Average rating: 0
(0 votes)

How do you track the performance of your application? When you instrument your app, there are more and more things you want to measure. Here we are to simplify your task and define the most important moments to monitor in Rails. As Ruby on Rails agency, Syndicode has compiled Ruby on Rails metrics measuring list for you. 

From our practice, we can tell a lot about getting metrics out of a Rails application. What things to consider? The general health of your application could be measured with:

  1. Request Count
    Request count is a total number of requests handled by the Rails app. Useful as a general measure of site traffic.
  2. Total Request Time
    The elapsed time between the request reaching the Rails app and a response being returned. This will be a good indication of how the performance of your application may be affecting user experience.
  3. Database Time
    Database Time is the amount of the total request time spent interacting with the database. It can help you identify problematic queries.
  4. Service Time
    This is the amount of the total request time spent interacting with external services. Along with the database time, this likely accounts for a large chunk of your total request time.
  5. Template Rendering Time
    This is the amount of the total request time spent rendering the view. Hopefully, this is a small portion of the request time (you don’t have any business logic in your views, right?)
  6. Queueing Time
    Queueing time is the time a request spends between the app server and the Rails process. This is a common cause of hidden latency in your application’s overall response time.
  7. Error Count
    The total number of errors raised that aren’t being handled by your application. Indicates that there may be problems with your infrastructure or the application itself.
  8. Status Code Counts
    This is the count of requests that resulted in the different HTTP status codes. Much like the error count, a spike in 4xx or 5xx status codes may signal a problem in your application environment.

These are the basic things you have to monitor. But, obviously, not all of the metrics you could measure. You should also keep in mind your network performance that hugely affects the performance of your application. Another thing to be aware of is security vulnerabilities. Recently we’ve covered this topic in our material Security issues solutions in RoR.

But let’s go back to our main parameters to monitor. How can we measure them?

1. Frist of all, Rails has great support for filters that allow you to run custom code before, after or “around” any controller action. In fact, if you configure a filter in the ApplicationController it will be run on every action in your application.

2. However, Rails is already tracking and measuring all of the things that we’re interested in. And we can tap into that data with no need to instrument it ourselves! All of the stats you see in the log output are available by hooking into the ActiveSupport instrumentation API. Rails has defined a number of different events you can subscribe to with a custom listener. These events include things like the execution of controller actions (process_action.action_controller), the rendering of templates (render_template.action_view), and ActiveRecord queries (sql.active_record).

With each of these events Rails delivers all sorts of useful data:

  • Name of the event
  • Start and end time for the event
  • Unique event ID
  • Name of the exception class and the exception message (if an error occurs during the event)

Also, different events can provide a custom, event-specific payload. For example, the process_action.action_controller event provides all of the following data: name of the controller and action, HTTP request parameters and status code, request method and path, response format, elapsed time for rendering view and elapsed time for executing database queries…

When you have all the data, you have to be attentive and careful about how to translate it. You should be able to see if your measured data is a sign that you need to optimize your queries. Or you have to be ready to change your cashing strategies if your template rendering time increased, for example.

To get more on this topic we recommend you check Performance Testing Rails Application. But remember, that if you new to this, you should better ask professionals for help.

Stay tuned and subscribe to our weekly newsletter to get more interesting stuff right into your mailbox.

Rate this article, if you like it

Thanks! You’ve rated this material!

Got a project? Let's discuss it!

*By submitting this form you agree with our Privacy Policy.

Mailing & Legal Address

Syndicode Inc. 340 S Lemon Ave #3299, Walnut CA, 91789, USA

Visiting & Headquarters address
Kyiv Sofiivska 1/2a, 01001, Kyiv, Ukraine
Dnipro Hlinky 2, of. 1003, 49000, Dnipro, Ukraine
Email info@syndicode.com
Phone (+1) 9035021111