Question
AES - Interpreting Performance indicators
How bad are these numbers? For one of the screens - we are getting AES alerts and the KPIs are as below.
Also advise on what can be done.
Accepted Solution
Is this from a PEGA0001 alert? What is the "other alert"? What are the elapsed times?
The underlined numbers are not specifically problems. 109k of output is not a big deal. 2.4MB of input is high - just what are you reading? How big is your work object?
I see pxOtherCount of 56, suggesting that there were a lot of rules cached. If you re-run your test case three times, does that number drop?
Is this from a PEGA0001 alert? What is the "other alert"? What are the elapsed times?
The underlined numbers are not specifically problems. 109k of output is not a big deal. 2.4MB of input is high - just what are you reading? How big is your work object?
I see pxOtherCount of 56, suggesting that there were a lot of rules cached. If you re-run your test case three times, does that number drop?
"Number of read operations for rules (not the number executed) from the PegaRULES database or the rule cache, for rule types with an Applies To key part."
2889 rules used is not a red flag - though declarative rules can sometimes take a while.
Note pxDeclarativePageLoadCount = 5 -- Does your application use data pages for transaction-specific data, or are are you taking a penalty for one-time loading of reference data?
PAL stats tell part of the story but you need the full alert, and other alerts from same interaction if applicable, to tell a more complete story. PAL time elapsed fields are often interesting - can you see in general most of the time elapsed, or were you stuck / waiting on events outside of your particular thread and requestor?
Going by the article and below list, they are not that bad. But how to understand this phrase "Metrics per session/hour" and how to interpret the maximum value given for each of these?
Ref article: https://docs-previous.pega.com/performance/alerts-alert-analysis-tools-and-usage-guidelines
Accepted Solution
Is this from a PEGA0001 alert? What is the "other alert"? What are the elapsed times?
The underlined numbers are not specifically problems. 109k of output is not a big deal. 2.4MB of input is high - just what are you reading? How big is your work object?
I see pxOtherCount of 56, suggesting that there were a lot of rules cached. If you re-run your test case three times, does that number drop?
Is this from a PEGA0001 alert? What is the "other alert"? What are the elapsed times?
The underlined numbers are not specifically problems. 109k of output is not a big deal. 2.4MB of input is high - just what are you reading? How big is your work object?
I see pxOtherCount of 56, suggesting that there were a lot of rules cached. If you re-run your test case three times, does that number drop?
"Number of read operations for rules (not the number executed) from the PegaRULES database or the rule cache, for rule types with an Applies To key part."
2889 rules used is not a red flag - though declarative rules can sometimes take a while.
Note pxDeclarativePageLoadCount = 5 -- Does your application use data pages for transaction-specific data, or are are you taking a penalty for one-time loading of reference data?
PAL stats tell part of the story but you need the full alert, and other alerts from same interaction if applicable, to tell a more complete story. PAL time elapsed fields are often interesting - can you see in general most of the time elapsed, or were you stuck / waiting on events outside of your particular thread and requestor?
Yes, this is a Pega0001 alert. screenshot below gives the elapsed time details on the alert.
This alert is shown for a scenario where we do a claim search and show the claim data on UI along with the assignment data. (OOTB case contents UI). But, this case contents area is populated with couple RDs one of which is actually resulting in fetch the blog. After multiple runs, the number did drop to single digits.
Does your application use data pages for transaction-specific data, or are are you taking a penalty for one-time loading of reference data? As for this, yes - we are using data pages for transaction specific data. I did not understand second part of this sentence - could you elaborate please?
