/
Application Performance Monitoring (APM)

Application Performance Monitoring (APM)

The APM gives you an overview of how your application is performing: performances, error rate, throughput, transactions per second, etc...

Transactions

You can track Web Transactions (API calls) and Non-Web Transactions (background jobs)

APDEX score

Apdex (Application Performance Index) defines a standard method for reporting and comparing the performance of software applications in computing.

It is an indicator of how responsive your application is received by an end-user. The formula can be configured under the Settings > Application.

Troubleshoot slow transactions

When navigating to the transactions tab, you can find the list of most time consuming transactions.



Transactions taking more than a configured threshold will be listed under the transaction traces and can be analysed more precisely to identify bottlenecks.

The list of usual suspects to look at:

  • Slow database queries (missing index, in-memory aggregation of data, N+1)
  • Nested loops
  • Lack of caching

Good tips to improve ruby code performances can be found here: https://github.com/JuanitoFatas/fast-ruby

Databases

This gives extremely useful information about your database queries and response times. It helps you finding inefficient database queries which most of the time are the applications bottlenecks.

Slow database queries will be listed on this page with hints to improve performances. Always make sure the SQL queries use indexes !

Ruby VMs

The Ruby Virtual Machine manages the memory allocation throughout objects life-cycle. The Garbage Collector (GC) kicks in to destroy unreferenced objects and free memory space.

If your Ruby VM runs out of memory, the GC is executed more often to free memory space. If no object can be destroy, the Ruby process will run out of memory, the GC will require a lot of CPU and the server will become slower. This kind of memory leak needs thorough inspection of the code to be addressed.

Things to look at:

  • Are the objects instantiated referenced in an array, other objects via associations
  • Are unbound collections loaded via has_many associations
  • Can objects processing be batched (look at ActiveRecord find_each and find_in_batches methods)
  • Are large files loaded (CSV, JSON) and parsed in memory

Errors

Your Web Application returns errors on invalid requests, as this is a normal behaviour, it still needs to be monitored. By default, if the error rate is above 5%, an alert will be triggered. If your application is correctly configured, this threshold can be lowered.

Improve the configuration

Ignore ping URLs

For a better reliability of the error rate, you should avoid tracking the ping URLs of your application. This can be achieve by specifying the following configuration in your newrelic.yml file

rules:
  ignore_url_regexes: ["^/ping", "^/health_check", "^/version"]

Ignore scanning requests

Hosting a publicly accessible application means that it will be scanned by external scripts to find vulnerabilities. You can exclude requests to any scripts with extensions php, asp, cgi etc...

Address errors

It is a good practice to periodically go through the errors captured by NewRelic even if it stays below the 5% error rate.

The complete stack trace is given to help you find the parts of the code that cause errors.

Related content