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.
The effect of applying PCLs can be seen in the following parts of the system: Dashboard/dashlets, Reports, Watchpoint export APIs.
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
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.
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.
Time for the object or page data to be transferred across intervening networks.
Time required for the browser to load the page.
The page-render time (PRT) metric measures the time to render all 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, which is often used for applications with any of the following characteristics:
Because the 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 .
Time spent redirecting the user to this page.
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
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
To characterize the end user experience as frustrated, tolerating, or satisfied, based on the performance metrics, configure PCLs according to the following procedures.
In a Real User Analyzer, point to Administration > Thresholds and problem detection, and click System Performance Compliance Levels (PCLs).
By default, every Watchpoint uses the system PCLs defined on the Administration > Thresholds and problem detection > System Performance Compliance Levels (PCLs) page. But you can configure unique PCL values for any, or even every Watchpoint.
In a Real User Analyzer, point to Watchpoints and click Available Watchpoints.