What comes to your mind when you hear terms like performance tuning or performance enhancement?
You may think of fine tuning various components of the applications and environments to enhance the application’s performance. But when is the right time to do so?
As a support engineer, I’ve handled multiple cases related to performance management. In nearly all scenarios, the theory of performance management came into picture only after hitting a roadblock. Most of the time, the roadblocks are quite critical with potential of incurring great amount of loss to customers.
Why does it always happen in this way? Why should one wait until they face the problem to fix the issue? As Benjamin Franklin said, “An ounce of prevention is worth a pound of cure. ” The same can be applied here as well.
Typically, during a development phase and testing phase, developers mainly focus on implementing and testing the use cases defined by business, and checking and addressing alerts on a regular basis can take a back seat as the reparations of alerts are not very visible during the development phase. While Pega does offer solutions like Autonomic Event Services (AES) or Predictive Diagnostic Cloud (PDC) to track the performance, they are most likely installed only to monitor production environments. While in a lower environment, one has to check the alerts manually and keep addressing them to make sure that the application remains healthy.
Amidst 100 or so alerts, how can you identify the most critical ones that the developers should not ignore?
Some of the critical alerts that developers should try to address as soon as they see them during development or testing are:
- Pega0001 — HTTP interaction time exceeds limit
This alert gets generated when the elapsed time for an HTTP interaction time exceeds the threshold setting. This typically happens when server response is slow or some activity is taking a long time to process. Watch out for the activity and make sure to tune it so that it does not take too much time to execute.
- Pega0004 — Quantity of data received by database query exceeds limit
This alert typically happens due to a poorly designed report. If you encounter this alert, watch out for the report involved and modify it by either limiting the returned result or by providing more filter criteria.
- Pega0005 — Query time exceeds limit
You’ll see this alert when the elapsed time for a query to the PegaRULES database exceeds the operation time threshold setting. When you encounter it, identify the SQL Query and tune it with the help of a DBA (database administrator).
- PEGA0019 — Long-running requestor detected
You’ll see this alert when a requestor tries servicing one interaction for a long-elapsed interval. Going to System Management Application (SMA) and killing the requestor is one option, but if you see this alert frequently that means there is a problem with the way some of the use case is designed. Check whether your activity (associated with the alert) is running into any sort of infinite loop or not. If yes, redesign the use cases to avoid the issue.
- Pega0031 — Generated stream overwritten and not sent to client
This alert comes when a generated stream has been overwritten without ever being sent to a browser client. If heavily ignored during development, this alert has the potential to cause a catastrophic damage to your application by stopping the desired UI to load at runtime. Watch out for the associated activity and see whether the successive interval has more than one stream generation command.
This is a sampling of alerts to watch out for and developers should try to address these as soon as possible.
For more detail about performance alerts, security alerts, and more, refer to the related links below.