ÃÛ¶¹ÊÓƵ

Issue

Troubleshooting

Resources

Low Apdex score:

Your New Relic measures users' satisfaction with the response time of your web applications and services.

You log in to > APM > Overview. On the right side of the Overview page you see the Apdex score graph. An Apdex score of 0.5 or less is a point of concern and warrants investigation: Web-transaction times (server requests):

1. 1. Log in to > APM > (Select an app) > Overview. Make sure the filter is set to Web transactions time on the main chart drop-down filter. Below in the Transactions table, look for App server time. Verify if you have any long-running or suspicious transactions.

   2. Investigate them individually by going to Monitoring > Transactions and make sure to set the filters for Web and Most time-consuming .

   3. Then search for third-party modules that consume resources: payment providers, ERP, etc.

   4. In the Monitoring section of APM:

      1. Click Transactions.
      2. Scroll down, click Show all transactions table.
      3. You can sort transactions by and jump to those that cause suspicion.
      4. Review those transactions with a low Apdex score, unusually high Count or high Avg time, or Dissat %.
      5. Click on each individual transaction. If you cannot resolve the issue, submit a support ticket.
      6. If you need to investigate further, consider checking non-web transactions.

Non-web-transaction time (operations and background tasks):

1. 1. Log in to > APM > (Select an app) > Overview. Make sure you select Non-web transactions time on the main graph drop-down filter. Click individual transactions in the Transactions table. Look for long-running or suspicious transactions. This includes backend jobs, cron jobs or import/export jobs, including third-party.

To learn more about New Relic Apdex score, refer to . You may also refer to Managed alerts for ÃÛ¶¹ÊÓƵ Commerce: Apdex warning alert in our support knowledge base.

High CPU usage:

High CPU usage can indicate there is a particularly busy service, like MySQL, Redis, etc.

1. Log in to > Infrastructure > Processes.
2. Review CPU graphs to see if there is any stuck or high-consuming process that is using more than 100% CPU time and compare against processor count on the instance. Pay attention to peaks in resource utilization. It is not recommended that you kill a process unless it is a stuck cron.

To learn more about performance metrics, particularly CPU percentage, I/O bytes, and memory usage for individual or groups of processes, refer to .

High I/O operations: For each customer, this number would be individual but will be significantly different from the average.

Look for an unusual spike compared to previous average I/O operations:

1. Log in to > Infrastructure > Processes.
2. Review I/O Read Bytes Per Second graph.
3. Record the time of the spike.
4. Click on APM.
5. Make sure you select web transactions time on the main graph drop-down filter.
6. Set the time for the time of the spike you recorded.
7. Search for transactions that have caused high I/O operations.
8. Drill down into each Transaction trace > Trace details to find what might be causing issues.

Outage: New Relic determines outages by Apdex. You will see a red line on the Apdex score graph, which indicates Apdex < 0.4, which is considered an outage.

Investigating an outage may take several steps, examining web and non-web transactions, databases and third-party transactions. Web Transactions:

1. Log in to > APM > Overview. Make sure the filter is set to Web transactions time on the drop-down graph filter.
2. Manually narrow the time window.
3. Click on Transactions. Make sure the filters are set to Web and Most time-consuming. Investigate the longest-running transaction.
4. If you need to investigate further, consider checking non-web transactions.

Non-web Transactions:

1. Go back to the Overview page and switch to Non-web transactions on the drop-down filter.
2. Review transaction traces at the very bottom of the page, one by one.
3. Depending on the issue, you may need to use a third-party tool like a PHP profiler to find a bottleneck.
4. If you need to investigate further, consider examining database processes.

Database processes:

1. On the APM page, go to Monitoring > Databases.

2. Sort by Most time-consuming.

3. Review TOP queries.

   Note: UPDATE or INSERTqueries are the most CPU-consuming queries.

4. Switch to Throughput from Sort by selector and look for processes that have caused the database throughput to drop-down.

5. If you need to investigate further, consider examining third-party services.

Third-party services:

1. On the APM page, go to Monitoring > External services.
2. Select the Slowest average response time from Sort by drop-down list.
3. Look for processes that occurred just before the outage.

To learn more about investigating specific performance problems, refer to .