Apdex is an industry standard to measure users' satisfaction with the response time of web applications and services. It's a simplified Service Level Agreement (SLA) solution that helps you see how satisfied users are with your app through metrics such as Apdex score and dissatisfaction percentage instead of easily skewed traditional metrics such as average response time.
Setting useful thresholds for your Apdex levels help you:
- See at a glance your end users' overall satisfaction with your app.
- Get the right amount of traces to troubleshoot and improve app performance.
To learn more, watch this short YouTube video (approx. 3:50 minutes).
How to use Apdex
The Apdex score is a ratio value of the number of satisfied and tolerating requests to the total requests made. Each satisfied request counts as one request, while each tolerating request counts as half a satisfied request.
An Apdex score varies from 0 to 1, with 0 as the worst possible score (100% of response times were Frustrated), and 1 as the best possible score (100% of response times were Satisfied).
Example Apdex score:
During a 2 minute period a host handles 200 requests. The Apdex threshold T = 0.5 seconds (500ms). This value is arbitrary and is selected by the user.
- 170 of the requests were handled within 500ms, so they are classified as Satisfied.
- 20 of the requests were handled between 500ms and 2 seconds (2000 ms), so they are classified as Tolerating.
- The remaining 10 were not handled properly or took longer than 2 seconds, so they are classified as Frustrated.
The resulting Apdex score is 0.9: (170 + (20/2))/200 = 0.9.
Important
The formula used for calculating the Apdex score is designed for high-throughput apps. If your app's throughput is less than 100 RPM, not enough data is collected to determine a stable score. The instability may result in Apdex alert conditions behaving unexpectedly.
Apdex counts
Apdex tracks three response counts:
- Satisfied: The response time is less than or equal to T.
- Tolerating: The response time is greater than T and less than or equal to 4T. In this example, 4 x 1.2 = 4.8 seconds is the maximum tolerable response time.
- Frustrated: The response time is greater than 4T or the request returns a server-side error. A high error rate can cause you to have a satisfying average response time, yet a poor Apdex score.
Your configuration file's apdex_f value is four times your app server's Apdex T value. This threshold is useful, for example, with transaction traces. For more information, see the configuration file documentation for your New Relic agent.
The time calculation will change based on your own app's T setting. In the following example, T = 1.2 seconds.
Level | Multiplier | Time (T Example = 1.2) |
|---|---|---|
Satisfied | T or less | <= 1.2 seconds |
Tolerated | >T, <= 4T | Between 1.2 and 4.8 seconds |
Frustrated | > 4T | Greater than 4.8 seconds |
After you define your Apdex levels, use any of New Relic's resources to help identify and troubleshoot changes that indicate poor customer experiences with your app.
You can define multiple Apdex T values for each of these:
Apdex measurements | Comments |
|---|---|
APM apps | APM monitors the performance of these apps. To define their Apdex settings, use the APM UI. You can find Apdex on the APM Summary page. |
Browser apps | Browser monitors the end-user experience for these apps. Instead of using Apdex to monitor your users, we recommend core web vitals. |
Key transactions | These are transactions important to your business that you choose to monitor. You can define Apdex settings for key transactions on the Key transactions page. ImportantThe key transaction Apdex setting overrides the T value of that app. For details, see Key transaction Apdex. |
Apdex alerting
You can also configure alert conditions for Apdex. When the Apdex score passes the threshold you define, New Relic sends an alert to the notification mechanism (channel).
Errors pages
Any request that returns a server-side error such as 500: Application Error is a frustrating response, regardless of its return speed. You can use Apdex to visualize the impact of these errors, and then identify and resolve these errors with New Relic's built-in error analytics and error profile tools.
Dissatisfaction percentage
The dissatisfaction percentage is the percentage of the total dissatisfaction experienced by the app's users that is contributed by a transaction.
Example Apdex dissatisfaction calculation:
Frustrations(Transaction) + Tolerations(Transaction)/2
Frustrations(App) + Tolerations(App)/2
To visualize dissatisfaction percentage, you can sort your transactions by most dissatisfying.
If a transaction is always frustratingly slow but rarely visited, it will not contribute much to the app's total dissatisfaction. Conversely, if a transaction is normally fast, but has high throughput, this may contribute a large proportion of the app's dissatisfaction simply because it contributes a large proportion of your app's traffic.
Customize Apdex visualizations
Use the query builder to customize how you visualize Apdex:
- Create dashboards to analyze and share your Apdex data.
- Analyze your Apdex data with NRQL queries.
Change Apdex settings
You can define Apdex T values for each application. You can also define individual Apdex T thresholds for key transactions.
For a quick overview of why Apdex measurements matter, and how to know what threshold is right for your application, watch this short YouTube video (approx. 3:40 minutes).