Defining system PCLs to measure user experience with an application
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.
Note
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 | 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 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 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 |
To characterize the end user experience as frustrated, tolerating, or satisfied, based on the performance metrics, configure PCLs according to the following procedures.
To configure system PCLs
In a Real User Analyzer, point to Administration > Thresholds and problem detection, and click System Performance Compliance Levels (PCLs).
- On the Action menu, click Edit.
- Adjust the settings as necessary.
For example, suppose that your web application is lightweight and the maximum page-render time is faster than the default value for Frustrated level (6,000 ms). You could change the frustrated level to 4,000 ms to consider a page-render time longer than 4 seconds as frustrated for your end users. - After you revise the values, click Save.
To configure PCLs for a particular Watchpoint
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.
- In a row for a given Watchpoint, on the Action menu, click Edit.
- In the Performance Compliance Levels (PCL) section, click Customize.
- For the necessary metrics, enter PCL values for the tolerating and frustrated levels.
If you do not specify PCLs for some metrics, the system will use the default values. If the PCLs that you enter duplicate the default values, then these values will be used even when the default values for system PCLs are changed. - Click Save.
You have configured PCLs for a Watchpoint. These PCL values are separate from and independent of system PCLs. You can change them only on the Watchpoint configuration page.
Related topic
Defining page SLTs to measure application performance compliance on the Analyzer
Comments
Log in or register to comment.