Page tree
Skip to end of metadata
Go to start of metadata

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:

  • The application embeds third-party content in the pages.
  • The application performs most processing on the client during content loading.
  • The application uses content delivery networks (CDNs) to cache content closer to the user. 

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

  1. In a Real User Analyzer, point to Administration > Thresholds and problem detection, and click System Performance Compliance Levels (PCLs).

  2. On the Action menu, click Edit.
  3. 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.
  4. 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.

  1. In a Real User Analyzer, point to Watchpoints and click Available Watchpoints.

  2. In a row for a given Watchpoint, on the Action menu, click Edit.
  3. In the Performance Compliance Levels (PCL) section, click Customize.
  4. 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.
  5. 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