System performance-compliance levels
Configurable system performance-compliance levels (PCLs) offer you a way to evaluate the performance and availability of your web application from the end users' perspective.
PCLs use the summary data to determine whether the overall traffic performed well or not. You cannot use them to determine whether a specific instance of a page had acceptable performance or not. More importantly, you can change the PCL values and your graphs of historical data will look different.
For each of the following metrics and attributes, you can set thresholds to characterize the experience that end users have with your web application as satisfied, tolerating, or frustrated. When performance is below the tolerating value, the system characterizes end users as frustrated. When performance exceeds the tolerating value, the system characterizes end users as satisfied.
Metrics and attributes to apply the PCLs to
Metric or attribute | Description |
|---|---|
E2E latency | Time it takes to deliver an object or page to the end user, starting from the time the first packet in the request is received until the browser acknowledges the delivery of the final packet in the response This metric measures the end-to-end latency of the entire object or page, including HTTP redirects. The system calculates this metric as the difference between the start time of the earliest element and the end time of the last element. |
Host latency | Time for the server to process the user's request and to generate a response This metric focuses on application responsiveness, ignoring the overhead of the network and the payload transfer time. Host latency time is calculated by totaling all latencies from the objects as effort. The system uses these effort totals to determine the percentage of effort required by the host. That percentage is then applied to the end-to-end time (minus any idle time for the page) to map the host effort to real time. Host Latency is typically used by SaaS vendors or other service providers that do not want poor network quality to affect the performance numbers. |
Network latency | Time for the object or page data to be transferred across intervening networks |
Page-render time | Time required for the browser to load the page The page-render time (PRT) metric measures the time to render all the content on a page, when all or some of the content comes from a source other than your origin server. The system uses a special web beacon target injected into web pages to derive PRT. To monitor the performance of content served by Akamai, you would use the page-render time metric. PRT is often used for applications with any of the following characteristics:
Because PRT metric measures from the start of page loading in the browser until the onLoad event, it incorporates many client-side impacts that would not be apparent to the server. Note: To use the PRT metric, you must first configure the reporting of page-render time. |
Redirect latency | Time spent redirecting the user to this page |
SSL latency | Time for the web system to negotiate SSL encryption for this object or page (not applicable if the page was not encrypted) |
TCP average latency | Average Transmission Control Protocol (TCP) time between the client and the server as observed throughout this request or page, in milliseconds |
Throughput | Effective throughput of the object or page request, in bits per second. It might be blank if the request was too small to accurately measure throughput |
Percentage of aborts | Percentage of requests that have been aborted |
Percentage of errors | Percentage of requests with errors |
Related topic