Application performance issues
A system performance monitoring program includes monitoring environmental resources such as application JVM memory usage, application server CPU performance, database server performance, and application performance. An important first step when identifying performance issues is understanding Pega’s use of multi-tier client-server architecture. The multiple handoffs among these application tiers can create difficulty identifying the source when a performance issue occurs.
External tools are available to monitor the environmental components, such as CPU utilization. Performance degradation can be a symptom of inadequate environment resources but are often a symptom of application design and configuration oversights. Pega Platform™ applications provide internal monitoring of performance and tools to identify common development and performance inefficiencies.
Diagnosing performance issues requires understanding the root cause of an issue. For example, a user might report that an application takes a minute to render a form. The actual underlying issue may be caused by a limited environmental resource, database interactions, rules assembly, or a browser rendering to find a resolution.
Design-time performance analysis
Poor application design can result in an application that has limited reusability, is hard to maintain, or has performance bottlenecks that are hard to diagnose and resolve. Guardrails are application design best practices that can help reduce the risk of introducing these types of issues.
Pega Platform monitors the rules that you create in your application for compliance with predefined guardrails. If a rule violates a guardrail, Pega Platform applies a warning to the rule. This warning indicates the severity and type of error that may result and often describes how to address the violation. Each warning indicates a particular issue with the configuration of the rule, and each rule may indicate multiple warnings. Pega Platform performs guardrail examination when saving a rule.
For example, a property that is not optimized for reporting and embedded in the case data BLOB can result in poor performance when executing a report. The system displays a guardrail warning message to alert you to the potential performance impact when you attempt to save a report definition that violates this best practice.
Review guardrail warnings to identify design aspects of the application unaligned with the guardrails and then make informed decisions about how to best address any guardrail violations. To enable you to quickly assess the overall quality and severity of guardrail warnings of an application, Pega Platform provides a compliance score. Guardrail scores and warnings are applied to each application and do not include Pega Platform core rules. The compliance score measures the number of rules with severe or moderate guardrail warnings, compared to the number of rules with no warnings or caution-level guardrail warnings. The Application Guardrails landing page in Dev Studio generates and displays the compliance score of the application.
Because new releases of Pega Platform add new guardrail validations and warnings, reassess guardrails or revalidate rules following an application update. When a client application updates to a newer release, any new guardrail best practices do not automatically apply to rules that already exist in the application. Rules from earlier releases need to be reevaluated to apply the new Guardrail warnings. Pega Platform provides a feature to revalidate rules by ruleset, so the new warning is applied to old rules. For more information on executing the revalidation process, see the Pega Community article About the bulk Revalidate and Save tool.
Check your knowledge with the following interaction.
The best way to create a high-performance application is to follow guardrails and other design and implementation best practices throughout the development cycle.
However, you can identify some performance issues, such as slow response times, only with actual performance testing and monitoring methods. Performance testing should include unit and load testing. Run-time performance monitoring provides invaluable alerts for both testing strategies.
Run-time performance analysis
System performance has many dimensions. For example, end users typically believe that system performance is synonymous with response time — the number of elapsed seconds between a request and a reply. At a business level, an important measure of system performance is throughput — how many completed units of work are processable per minute, hour, or workday. Because performance has many dimensions, agreement on goals and measures of success is an important first step in performance testing analysis.
At run time, Pega Platform generates system alerts based upon various performance thresholds you set in the prconfig.xml file or Dynamic System Settings. The alert is a text entry or message indicating that a specific interaction or rule execution has exceeded a performance threshold. The message also identifies the type of requestor (for example, browser or batch requestor), and the activity or stream that triggered the alert.
The following text illustrates a threshold violation alert.
Pega Platform writes the alerts to the performance alert log during application processing. You can view the alert log in Dev Studio by clicking Configure > System > Operation > Logs and choosing Alert. Pega Platform also offers the Predictive Diagnostic Cloud (PDC) monitoring application to capture, analyze, and manage alerts. The on-premise version of PDC is also known as Pega Autonomic Event Services (AES). These applications greatly enhance monitoring features by providing a health-check dashboard, enhanced analytics, and database table index recommendations.
Check your knowledge with the following interaction.
Identification of performance issues by using alerts
Identifying the cause of performance issues in an application can be challenging. An application can present various performance issues such as excessive response times, lengthy request result sets, invalid data returns, database deadlocks, and too many open connections.
For example, performance issues reported by end users, such as excessive response times, may be caused by a poorly written SQL query in the application, network latency, or performance issues with the database server.
Performance alerts can also help you to identify the root cause of a performance issue. You can use a combination of alerts to identify the pattern or cause for a specific alert to appear frequently. For example, to troubleshoot an excessive response time issue, the following alerts can help you identify the cause.
Pega Platform currently handles over a hundred different types of alerts. To view a complete list of alerts and the reasons for receiving one, see the Pega Community article List of performance and security alerts in Pega Platform.
Some of the more common alerts include:
|Error number||Error name||Reasoning|
|PEGA0001||HTTP interaction time exceeds limit||Exceeding a time threshold for long-running calculations, waiting for database connections or responses, or waiting for information from an external service|
|PEGA0004||Quantity of data received by database query exceeds limit||Exceeding a byte threshold when a query loads an excessive quantity of data|
|PEGA0005||Query time exceeds limit||Exceeding a time threshold for a query to run|
|PEGA0026||Time to connect to database exceeds limit||Exceeding a time threshold to connect to a database|
|PEGA0030||The number of requestors for the system exceeds limit||Exceeding a numerical threshold for the number of requestors|
|PEGA0002||Commit operation time exceeds limit||Exceeding a time threshold for a database commit operation|
Adjustment of performance alert thresholds
Pega Platform provides more than 100 built-in performance alerts and a dedicated log file that help you to identify individual atomic operations that exceed the performance thresholds. While advanced performance analysis requires deep technical skills to interpret and act on typically large volumes of data, Pega Platform provides easy-to-use alerts and associated logs that can help you understand the performance impacts of the rules you create for an application.
In a development environment, some performance alerts are usually transient and caused by tasks that do not occur at run time in a production environment. However, many performance alerts triggered in a development environment provide an early warning that a recently executed rule, or a combination of rules, exceeds established performance thresholds. While you can choose to ignore these performance alerts or effectively disable them through settings changes, these performance alerts provide valuable early clues about rules that affect overall performance.
Because application performance has many dimensions, agreement on goals and measures of success is an important first step in a performance improvement effort. Load testing often identifies performance issues before the issues are experienced in the production environment. Some changes to performance thresholds provide clear advantages. For example, reducing the number of rows retrieved from the PegaRULES database also reduces the number of bytes sent over the network and likely reduces the amount of memory needed to store the data on the server.
Other changes may involve tradeoffs. For example, reducing demand for one type of resource (or increasing supply) adds to the demand for another type of resource. Such changes may improve performance by one measure but harm performance when assessed a different way. Identifying performance degradation and opportunities may take research. Improving one lightly-used task so that it is 200 percent faster is impressive, but the task may have a minor overall impact compared with a 2 percent improvement in a vital, heavily used task.
Performance alert thresholds have default values and may not be explicitly set in the application. The preferred method for adjusting performance thresholds is by using Dynamic System Settings (DSS), but you can choose to modify system settings in the prconfig.xml file. Alert thresholds can be maintained in the prconfig.xml, however current versions of Pega Platform have been enhanced so alert thresholds can be maintained with the use of DSS instances, as long as the prconfig.xml has the following parameter name and value set to <env name="initialization/settingsource" value="merged" />
Note: To set an alert threshold with a Dynamic System Settings record, prepend prconfig/ and append /default on to the setting purpose.
Note: If a prconfig setting is defined in a prconfig.xml file and is also defined through a Dynamic System Setting, the prconfig.xml takes precedence
To add a DSS record for performance thresholds, you define the:
- Short description – Use a short, descriptive phrase that describes the purpose or intent of the performance threshold. For example, the short description for a DSS record that defines the default HTTP interaction threshold might be HTTP interaction time threshold.
- Owning ruleset – The owning ruleset for any DSS record used to set performance thresholds initialized in prconfig.xml is the Pega-Engine ruleset. Pega Platform does not allow you to create a performance threshold DSS record with an owning ruleset other than Pega-Engine.
- Setting purpose – In a DSS record, performance-related threshold setting entries are written in the form: prconfig/[performance-related threshold setting name]/default. For example, to create a DSS record that adjusts the HTTP browser interaction time threshold, enter prconfig/alerts/broswer/interactionTimeThreshold/warnMS as the setting purpose.
- Node classification – Specify which nodes the setting should be applied. To have the setting applied to all nodes, specify /default. Alert threshold settings are generally applied to all nodes. For more information about node classification, see Learning about default dynamic system settings.
- Value – Specify the threshold value. The unit of measure for each alert threshold is documented in the Pega Community article List of performance and security alerts in Pega Platform. In the following image, the value is in milliseconds.
Note: You need to restart the application server before changes to performance-related DSS entries take effect.