Question
Pegasystems Inc.
IN
Last activity: 13 Apr 2022 10:23 EDT
PEGA0001 alert followed by a PEGA0037 alert and observing UI slowness
I am in a situation where I see UI response is slow (on average 10sec) for all the operations and case creation. On diagnosis, I could see lots of PEGA0001 alerts and right before that there are multiple PEGA0037 alerts.
Also this being a production environment, there are no chances of rule updates but still rule assembly is happening and its taking longer time. There is no instances of Temp directory being cleared.
Will static assembly work in this case and what could be the possible reason for this issue.
Thanks!
Accepted Solution
Updated: 13 Apr 2022 10:23 EDT
Ernst & Young LLP
MT
See if this article helps: https://docs-previous.pega.com/performance/how-reduce-rules-assembly-processing-production-system
Updated: 22 Feb 2022 12:30 EST
Pegasystems Inc.
GB
@PraveenJayaraj this issue might be too involved to answer on a forum, however here are some pointers.
I'm assuming you will already have checked the following post and the help files:
1. PEGA0037 alert: Rule assembly time exceeded threshold
Reasons for the alert This alert can occur in the following situations:
Cache setting needs adjustment, for example, your rule cache might be too small. A systemic problem exists, for example, database response time is slow or the network performance is suboptimal. Run the static assembler for the application to preassemble the application rules.
2. PEGA0001 alert: HTTP interaction time exceeds limit
Reasons for the alert If your alert log contains a large number of PEGA0001 messages, a problem on the server might be causing a significant slowdown. Check the server for the underlying problem.
If the text message identifies an activity, the activity might be taking an extremely long time to process. Use the PAL performance tool or DBTrace to check which steps the activity is running.
Questions:
- You have not specified what version of Pega you are on.
@PraveenJayaraj this issue might be too involved to answer on a forum, however here are some pointers.
I'm assuming you will already have checked the following post and the help files:
1. PEGA0037 alert: Rule assembly time exceeded threshold
Reasons for the alert This alert can occur in the following situations:
Cache setting needs adjustment, for example, your rule cache might be too small. A systemic problem exists, for example, database response time is slow or the network performance is suboptimal. Run the static assembler for the application to preassemble the application rules.
2. PEGA0001 alert: HTTP interaction time exceeds limit
Reasons for the alert If your alert log contains a large number of PEGA0001 messages, a problem on the server might be causing a significant slowdown. Check the server for the underlying problem.
If the text message identifies an activity, the activity might be taking an extremely long time to process. Use the PAL performance tool or DBTrace to check which steps the activity is running.
Questions:
- You have not specified what version of Pega you are on.
- How long has this issue been occuring?
- You mention slowness in "UI response" - is it specific to certain complex sections? Can you clarify which ones, and do all users see the problem?
- What does 'case creation' entail (connectivity/ service issues?)
- What are the exact symptoms of the timeout?
- Did you check in PDC/AES to see which pega alert the timeout is caused by?
- How long does the user wait, and how does the user need to rectify to log back into the application?
Regarding rule assembly, some issues were improved in later patch releases. Did you already check details regarding 'Running Static Assembler in utility mode' and 'Temporary files ' ?
Changes are Done in ProcessEngineUtilsImpl.java > getApplicationRuleSetList() method to avoid repetitive and redundant calls to open / cache application Details. Improvements can be found from 8.5.6 . Case creation and Save As performance improvements have been made to the getApplicationRuleSetList() function to avoid unnecessary and repetitive database calls. Also fixed in: 8.4.5, 8.5.4, 8.5.6, 8.6.1 and 8.6.3
- Can you replicate the issue on your Dev?
- Did you analyse your pegaALERT logs more closely to try to pin down the source of the errors?
- Did you already log a support incident for this? Artefacts we would ask you to collect:
- A tracer capture with DB Cache and DB Query selected
- Corresponding pegaRULES and ALERT log files while performing the operations
- Additional log files / information from the WebUser Nodes covering the time of the Trace operation:
Accepted Solution
Updated: 13 Apr 2022 10:23 EDT
Ernst & Young LLP
MT
See if this article helps: https://docs-previous.pega.com/performance/how-reduce-rules-assembly-processing-production-system