Difference between revisions of "Best practices for implementing high performing Pega Sales Automation applications"

From PegaWiki
Jump to navigation Jump to search
m (updated)
Tag: Visual edit
m (updated)
Tag: Visual edit
Line 22: Line 22:
  
 
As part of performance testing for Pega applications, focus on the following performance tools located in Dev Studio:
 
As part of performance testing for Pega applications, focus on the following performance tools located in Dev Studio:
 +
* Memory footprint (Performance tool)
 +
* CPU utilization
 +
* Database queries
  
·        Memory footprint (Performance tool)
+
=== Memory footprint ===
 
 
·        CPU utilization
 
 
 
·        Database queries
 
 
 
== Memory footprint[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 2|[KMR2]]] ==
 
 
The memory footprint of a user is determined by the size of the individual cases multiplied by the number of cases that are open during the working session. Memory footprint on the server is critical for sizing a system to accommodate expected user load while leaving sufficient head room for occasional traffic spikes. Out of memory errors cause nodes to crash and result in disruptions to users who lose their unsaved work.
 
The memory footprint of a user is determined by the size of the individual cases multiplied by the number of cases that are open during the working session. Memory footprint on the server is critical for sizing a system to accommodate expected user load while leaving sufficient head room for occasional traffic spikes. Out of memory errors cause nodes to crash and result in disruptions to users who lose their unsaved work.
  
Use the '''Performance''' tool in Dev Studio to examine the clipboard (memory) usage from screen to screen. Identify key scenarios and evaluate them step by step to assess memory usage. Run the Performance tool twice[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 3|[AK3]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 4|[KMR4]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 5|[AK5]]]  to validate that memory utilization is consistent and ensure, that there are no leaks caused by pages accumulating in the memory.
+
Use the '''Performance''' tool in Dev Studio to examine the clipboard (memory) usage from screen to screen. Identify key scenarios and evaluate them step by step to assess memory usage. Run the Performance tool twice[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 3 <nowiki>[AK3]</nowiki>] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 4 <nowiki>[KMR4]</nowiki>] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 5 <nowiki>[AK5]</nowiki>]  to validate that memory utilization is consistent and ensure, that there are no leaks caused by pages accumulating in the memory.
  
'''Using the Performance tool to collect footprint:'''[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 6|[AK6]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 7|[KMR7]]]
+
==== '''Using the Performance tool to collect footprint:''' ====
 +
# In the bottom-right corner of Dev Studio, click Performance.
 +
# Click Reset to reset the performance data.
 +
# Run the test scenario.
 +
# Click '''Add reading with clipboard size''' to collect the footprint.
 +
# Open the delta snapshot that was last added and examine the requestor clipboard size to determine if it is in threshold.
 +
## If the clipboard size is greater than 5 MB, examine it closer by performing the following steps:
 +
##* Examine Report definitions that are used to retrieve data to ensure they are using an optimized WHERE clause that returns only the data needed.
 +
##* Explicitly removing temporary pages (created say for running reports or fetching external data) reduces memory footprint.
 +
##  If the clipboard size is within the threshold, there are no issues with the application performance
 +
# Repeat steps 1 to 4 for each screen in the scenario
  
1)       In the bottom-right corner of Dev Studio, click Performance.
+
=== CPU utilization ===
 
+
CPU utilization by a user impacts the sizing of a system. Optimizing CPU usage results in faster response times experienced by the users and allows more users to run on the same hardware.  You can use this performance tool in a similar way as the memory examination to examine key metrics that impact the amount of work being done. For each screen in the scenario, users can “add reading” without the clipboard size and open the delta to examine the metric[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 20 <nowiki>[NV20]</nowiki>] .
2)      Click Reset to reset the performance data.[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 8|[AK8]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 9|[KMR9]]]
 
 
 
3)      Run the test scenario.[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 10|[AK10]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 11|[KMR11]]]
 
 
 
4)      Click '''Add reading with clipboard size''' to collect the footprint. [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 12|[AK12]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 13|[KMR13]]]
 
 
 
5)      Open the delta snapshot that was last added and examine the requestor clipboard size to determine if it is in threshold.[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 14|[AK14]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 15|[KMR15]]]
 
 
 
a)       If the clipboard size is greater than 5 MB, examine it closer by performing the following steps:
 
 
 
                                                       i)           Examine Report definitions that are used to retrieve data to ensure they are using an optimized WHERE clause that returns only the data needed.
 
 
 
                                                     ii)           Explicitly removing temporary pages (created say for running reports or fetching external data) reduces memory footprint.
 
 
 
b)      If the clipboard size is within the threshold, there are no issues with the application performance. [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 16|[AK16]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 17|[KMR17]]]
 
 
 
6)      Repeat steps 1 to 4 for each screen in the scenario.[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 18|[AK18]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 19|[KMR19]]]
 
 
 
== CPU utilization ==
 
CPU utilization by a user impacts the sizing of a system. Optimizing CPU usage results in faster response times experienced by the users and allows more users to run on the same hardware.  You can use this performance tool in a similar way as the memory examination to examine key metrics that impact the amount of work being done. For each screen in the scenario, users can “add reading” without the clipboard size and open the delta to examine the metric[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 20|[NV20]]] .
 
  
 
An executed interaction excessing 15K rules can likely be optimized.  If the interaction exceeds this threshold, most probably some complex or unoptimized logic was used.
 
An executed interaction excessing 15K rules can likely be optimized.  If the interaction exceeds this threshold, most probably some complex or unoptimized logic was used.
 +
* Evaluate this logic to identify potential areas for improved design that can reduce the cost of running interactions.
 +
* A large result set from a data query might cause the system to execute a large number of rules to process each result. You can reduce the processing impact, examine the business value of the data returned and reduce the size of the result set to the data required to complete the task.
  
·        Evaluate this logic to identify potential areas for improved design that can reduce the cost of running interactions.
+
=== Database queries ===
 
+
The volume and speed of access to the database is often a key factor in the performance of each application. The complexity and frequency of SQL queries are two metrics that you must analyze.  The default SQL queries complexity  threshold is 500. Use the tracer to see every query and its time to execute. You can use the performance tool to check the elapsed time spent in the database executing a report or requesting data from an external system through a connector.
·        A large result set from a data query might cause the system to execute a large number of rules to process each result. You can reduce the processing impact, examine the business value of the data returned and reduce the size of the result set to the data required to complete the task.
+
* If a single query is taking more than 200ms for a for a single query, then there is a potential performance issue. Use the tracer to examine each query executed and identify the queries that are over the threshold. Try to narrow the filter criteria and improve the WHERE clause.
 
+
* If the RDB I/O count is greater than 20, there might be a potential performance issue. Excessive queries to the database may be a sign of an improper query logic or a database schema that has been poorly designed. Check the queries to ensure that they are providing the business value needed. You can reduce repeated queries to the same table by improving the filter criteria of that query.
== Database queries ==
 
The volume and speed of access to the database is often a key factor in the performance of each application. The complexity and frequency of SQL queries are two metrics that you must analyze.  The default SQL queries complexity  threshold is 500. Use the tracer to see every query and its time to execute[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 21|[AK21]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 22|[KMR22]]] . You can use the performance tool to check the elapsed time spent in the database executing a report or requesting data from an external system through a connector.
 
 
 
·        If a single query is taking more than 200ms for a for a single query, then there is a potential performance issue. Use the tracer to examine each query executed and identify the queries that are over the threshold. Try to narrow the filter criteria and improve the WHERE clause.
 
 
 
·        If the RDB I/O count is greater than 20, there might be a potential performance issue. Excessive queries to the database may be a sign of an improper query logic or a database schema that has been poorly designed. Check the queries to ensure that they are providing the business value needed. You can reduce repeated queries to the same table by improving the filter criteria of that query.
 
----where can we find this memory footprint? is it a tool or a feature in a tool? we need to introduce this more [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]Performance tool in dev studio will be used to collect foot print [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]
 
 
 
why twice? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 3|[AK3]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 3|[AK3]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 4|[KMR4]]]Usually performance analysis will be done multiple times.  Second sentence will convey (to validate that memory utilization consistent).  This is because of cache. [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 4|[KMR4]]]
 
 
 
okay, thank you! [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 5|[AK5]]]
 
 
 
steps to do what? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 6|[AK6]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 6|[AK6]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 7|[KMR7]]]Steps to get memory foot print [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 7|[KMR7]]]
 
 
 
can we make the steps more detailed? where do I go to reset the performance data? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 8|[AK8]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 8|[AK8]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 9|[KMR9]]]Performance tool in Dev which I mentioned in second paragraph [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 9|[KMR9]]]
 
 
 
what do I click to run a test scenario? or is the test scenario in the app, not on the Performance tab? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 10|[AK10]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 11|[KMR11]]]Yes test scenarios is App
 
 
 
to do what? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 12|[AK12]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 12|[AK12]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 13|[KMR13]]]For collecting foot print in the performance tool they need to click on this button [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 13|[KMR13]]]
 
 
 
what if it's not? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 14|[AK14]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 14|[AK14]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 15|[KMR15]]]As this is comparison between old snapshot and current snapshot [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 15|[KMR15]]]
 
 
 
is this correct? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 16|[AK16]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 17|[KMR17]]]Correct
 
 
 
where are these scenarios? something testers create? [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 18|[AK18]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 19|[KMR19]]]Yes, correct
 
 
 
Std.  [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 20|[NV20]]]Hardware sizing recommendations (App server / DB server nodes) for a pega sales automation implementation should be included somewhere in the document.
 
 
 
time to load or time to run? I'd like to be more specific here [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 21|[AK21]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 21|[AK21]]]
 
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 22|[KMR22]]]There will be only one time that is time taken to execute the query [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 22|[KMR22]]]
 
  
 
== Guidelines for building a high-performing Pega Sales Automation application ==
 
== Guidelines for building a high-performing Pega Sales Automation application ==
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 2|[KMR2]]] If you want to build a high-performing application, you must concentrate on the following crucial areas because the way they are set up impacts application performance:
+
If you want to build a high-performing application, you must concentrate on the following crucial areas because the way they are set up impacts application performance:
 
+
* Data import
·        Data import
+
* User experience
 
+
* Clipboard and data pages  
·        User experience
+
* Monitor requestors for evaluating clipboard size
 
+
* Integration and connectors
·        Clipboard and data pages  
 
 
 
·        Monitor requestors for evaluating clipboard size
 
 
 
·        Integration and connectors
 
  
== Data import ==
+
=== Data import ===
 
Application performance if often impacted by the imported volume of data.  The following are a few recommendations related to data import to avoid degrading application performance:
 
Application performance if often impacted by the imported volume of data.  The following are a few recommendations related to data import to avoid degrading application performance:
 
* The size of the File Listener based upload    should not exceed 1 million records in a single file.
 
* The size of the File Listener based upload    should not exceed 1 million records in a single file.
Line 137: Line 72:
 
For more information about how to improve the application performance while importing data, see  Improve the data import performance by using configuration.
 
For more information about how to improve the application performance while importing data, see  Improve the data import performance by using configuration.
  
== User experience ==
+
=== User experience ===
 
How both the user experience and user interface are designed has a large impact on the application performance, both actual and perceived. To avoid poor performance, determine what information is important to display to users. See the following tips:
 
How both the user experience and user interface are designed has a large impact on the application performance, both actual and perceived. To avoid poor performance, determine what information is important to display to users. See the following tips:
  
Line 148: Line 83:
 
·        When building the show and hide logic, use expressions instead of When rules because expressions execute on the client-side instead of on the server-side. As a result, expressions perform faster and reduce the server-side load as you scale.
 
·        When building the show and hide logic, use expressions instead of When rules because expressions execute on the client-side instead of on the server-side. As a result, expressions perform faster and reduce the server-side load as you scale.
  
== Clipboard and data pages ==
+
=== Clipboard and data pages ===
 
There are several factors that are improving the application performance, for example, a clean clipboard on job scheduler requestors, file listener requestors, reasonable overall requestor clipboard size, and efficient and correct load strategies on data pages. A well-designed application provides a continuously responsive performance for job schedulers, file listeners regardless of their shift duration, and it must scale when there are many users per node.
 
There are several factors that are improving the application performance, for example, a clean clipboard on job scheduler requestors, file listener requestors, reasonable overall requestor clipboard size, and efficient and correct load strategies on data pages. A well-designed application provides a continuously responsive performance for job schedulers, file listeners regardless of their shift duration, and it must scale when there are many users per node.
  
Line 157: Line 92:
 
Always select the '''Clear pages''' setting after not using pages for read-only requestor-level data pages.
 
Always select the '''Clear pages''' setting after not using pages for read-only requestor-level data pages.
  
== Monitor requestors for evaluating clipboard size ==
+
=== Monitor requestors for evaluating clipboard size ===
 
Monitor requestors periodically for average size to help identify potential issues with loading too many items on the clipboard, pages not being cleared out, and users who do not close.
 
Monitor requestors periodically for average size to help identify potential issues with loading too many items on the clipboard, pages not being cleared out, and users who do not close.
  
Line 164: Line 99:
 
The key items to watch are the average page size of the requestor and the largest page sizes. On average, the requestor size should be 12MB or less across all system users.
 
The key items to watch are the average page size of the requestor and the largest page sizes. On average, the requestor size should be 12MB or less across all system users.
  
== Integration and connectors ==
+
=== Integration and connectors ===
 
Some Pega Sales Automation functionalities integrate with the external systems of record. When integrating with the external systems of record, to ensure high performance, follow these guidelines:
 
Some Pega Sales Automation functionalities integrate with the external systems of record. When integrating with the external systems of record, to ensure high performance, follow these guidelines:
  
Line 176: Line 111:
  
 
·        Directly reference connectors and their associated mapping, and if required, add a data transform after your connector sources, to perform any reconciliation or error handling after calling multiple interfaces.
 
·        Directly reference connectors and their associated mapping, and if required, add a data transform after your connector sources, to perform any reconciliation or error handling after calling multiple interfaces.
----we need an intro sentence here to introduce the section. We can't have a header under header  [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]]
+
----we need an intro sentence here to introduce the section. We can't have a header under header  [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1 <nowiki>[AK1]</nowiki>] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1 <nowiki>[AK1]</nowiki>]
  
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]How it would be following are some of the areas the need to concentrate to build high performance Pega applications [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]
+
How it would be following are some of the areas the need to concentrate to build high performance Pega applications [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2 <nowiki>[KMR2]</nowiki>]
  
 
== Tools for performance testing  ==
 
== Tools for performance testing  ==
 
Performance is an important aspect of any system. The perceived quickness of the system often measures user satisfaction and business value. Pega provides a full suite of tools to monitor and address performance. Use these tools during the development to ensure that your configuration performs optimally.  
 
Performance is an important aspect of any system. The perceived quickness of the system often measures user satisfaction and business value. Pega provides a full suite of tools to monitor and address performance. Use these tools during the development to ensure that your configuration performs optimally.  
  
To open system performance, in the header of Dev Studio, click Configure > System > Performance.
+
To open system performance, in the header of Dev Studio, click Configure > System > Performance.  
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 2|[KMR2]]]
 
  
 
Performance landing page
 
Performance landing page
Line 197: Line 130:
 
·        Performance Profiler.  
 
·        Performance Profiler.  
  
== These tools are also available by clicking the Performance tool in the toolbar. Use the performance tools to collect performance statistics. For more information, see Understanding system resources[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 3|[AK3]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 4|[KMR4]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 5|[KMR5]]] . ==
+
These tools are also available by clicking the Performance tool in the toolbar. Use the performance tools to collect performance statistics. For more information, see Understanding system resources.
  
== Analyze application performance with PDC ==
+
=== Analyze application performance with PDC ===
 
Pega Predictive Diagnostic Cloud (PDC) is a Software as a Service (SaaS) tool that runs on Pega Cloud® and actively gathers, monitors, and analyzes real-time performance and health indicators from all active Pega Platform™ applications. PDC gathers, aggregates, and analyzes alerts, system health pulses, and guardrail violations generated from Pega applications.
 
Pega Predictive Diagnostic Cloud (PDC) is a Software as a Service (SaaS) tool that runs on Pega Cloud® and actively gathers, monitors, and analyzes real-time performance and health indicators from all active Pega Platform™ applications. PDC gathers, aggregates, and analyzes alerts, system health pulses, and guardrail violations generated from Pega applications.
  
 
For more information, see  Analyzing application performance through PDC
 
For more information, see  Analyzing application performance through PDC
  
== Analyze application performance with Database Trace ==
+
=== Analyze application performance with Database Trace ===
 
The Database Trace generates a text file containing the SQL statements, rule cache hit statistics, timings, and other data that reflect the interactions of your requestor session with the Pega Platform database or other relational databases. Familiarity with SQL is not required to interpret the output.
 
The Database Trace generates a text file containing the SQL statements, rule cache hit statistics, timings, and other data that reflect the interactions of your requestor session with the Pega Platform database or other relational databases. Familiarity with SQL is not required to interpret the output.
  
Line 211: Line 144:
 
For more information, see Analyzing application performance through Database Trace
 
For more information, see Analyzing application performance through Database Trace
  
== Analyze application performance with Performance Profiler ==
+
=== Analyze application performance with Performance Profiler ===
 
The Performance Profiler is useful when determining which part of the process might be having performance issues, or identifying the particular step of a data transform or activity that might have a performance issue.
 
The Performance Profiler is useful when determining which part of the process might be having performance issues, or identifying the particular step of a data transform or activity that might have a performance issue.
  
Line 220: Line 153:
 
For more information, see Analyze application performance through Performance Profiler
 
For more information, see Analyze application performance through Performance Profiler
  
== Analyze application performance with Performance Analyzer ==
+
=== Analyze application performance with Performance Analyzer ===
 
The Performance Analyzer (PAL) provides a view to all the performance statistics that Pega Platform™ captures. Use PAL to understand the system resources consumed by processing a single requestor session.
 
The Performance Analyzer (PAL) provides a view to all the performance statistics that Pega Platform™ captures. Use PAL to understand the system resources consumed by processing a single requestor session.
  
 
To open PAL, in Dev Studio, click System > Performance or select the Performance tool in the toolbar.
 
To open PAL, in Dev Studio, click System > Performance or select the Performance tool in the toolbar.
  
For more information, see Analyzing application performance[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 6|[AK6]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 7|[KMR7]]] through Performance Analyzer.
+
For more information, see Analyzing application performance through Performance Analyzer.
  
 
Analyze the logs through PegaRules Log Analyzer (PLA)
 
Analyze the logs through PegaRules Log Analyzer (PLA)
Line 234: Line 167:
  
 
For more information, see PegaRules Log Analyzer
 
For more information, see PegaRules Log Analyzer
----we have to give this image a name (caption under it) and introduce it by a sentence [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1|[AK1]]]
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]Performance landing page.  Go to Dev Studio and click on configure à system à performance menu item [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2|[KMR2]]]
 
 
this must be a link [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 3|[AK3]]]
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 4|[KMR4]]]<nowiki/>changed
 
 
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 5|[KMR5]]]
 
 
this needs to be a link [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 6|[AK6]]] [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 6|[AK6]]]
 
  
[[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 7|[KMR7]]]<nowiki/>done [[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 7|[KMR7]]]
 
  
 
== Summary ==
 
== Summary ==
 
There are several tools that Pega Platform provides to implement high performing applications.   By using these tools you can analyze application performance, debug root causes for the performance decrease, and take necessary steps for further performance improvement.
 
There are several tools that Pega Platform provides to implement high performing applications.   By using these tools you can analyze application performance, debug root causes for the performance decrease, and take necessary steps for further performance improvement.

Revision as of 09:27, 26 January 2021


Curator Assigned
Request to Publish
Description
Version as of
Application
Capability/Industry Area

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.

When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Introduction[edit]

This article captures information related to analyzing performance of any Pega application by using the tools available in Pega Platform, as well as, best practices for implementing high performing Pega Sales Automation applications.

Analyze performance[edit]

Pega recommends testing for performance throughout the application development lifecycle.  Doing performance test during development cycles helps to optimize the application before it is pushed to production. Discovering and remediating performance issues in production application is disruptive and expensive.

As part of performance testing for Pega applications, focus on the following performance tools located in Dev Studio:

  • Memory footprint (Performance tool)
  • CPU utilization
  • Database queries

Memory footprint[edit]

The memory footprint of a user is determined by the size of the individual cases multiplied by the number of cases that are open during the working session. Memory footprint on the server is critical for sizing a system to accommodate expected user load while leaving sufficient head room for occasional traffic spikes. Out of memory errors cause nodes to crash and result in disruptions to users who lose their unsaved work.

Use the Performance tool in Dev Studio to examine the clipboard (memory) usage from screen to screen. Identify key scenarios and evaluate them step by step to assess memory usage. Run the Performance tool twice[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 3 [AK3]] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 4 [KMR4]] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 5 [AK5]]  to validate that memory utilization is consistent and ensure, that there are no leaks caused by pages accumulating in the memory.

Using the Performance tool to collect footprint:[edit]

  1. In the bottom-right corner of Dev Studio, click Performance.
  2. Click Reset to reset the performance data.
  3. Run the test scenario.
  4. Click Add reading with clipboard size to collect the footprint.
  5. Open the delta snapshot that was last added and examine the requestor clipboard size to determine if it is in threshold.
    1. If the clipboard size is greater than 5 MB, examine it closer by performing the following steps:
      • Examine Report definitions that are used to retrieve data to ensure they are using an optimized WHERE clause that returns only the data needed.
      • Explicitly removing temporary pages (created say for running reports or fetching external data) reduces memory footprint.
    2.  If the clipboard size is within the threshold, there are no issues with the application performance
  6. Repeat steps 1 to 4 for each screen in the scenario

CPU utilization[edit]

CPU utilization by a user impacts the sizing of a system. Optimizing CPU usage results in faster response times experienced by the users and allows more users to run on the same hardware.  You can use this performance tool in a similar way as the memory examination to examine key metrics that impact the amount of work being done. For each screen in the scenario, users can “add reading” without the clipboard size and open the delta to examine the metric[:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msocom 20 [NV20]] .

An executed interaction excessing 15K rules can likely be optimized.  If the interaction exceeds this threshold, most probably some complex or unoptimized logic was used.

  • Evaluate this logic to identify potential areas for improved design that can reduce the cost of running interactions.
  • A large result set from a data query might cause the system to execute a large number of rules to process each result. You can reduce the processing impact, examine the business value of the data returned and reduce the size of the result set to the data required to complete the task.

Database queries[edit]

The volume and speed of access to the database is often a key factor in the performance of each application. The complexity and frequency of SQL queries are two metrics that you must analyze.  The default SQL queries complexity  threshold is 500. Use the tracer to see every query and its time to execute. You can use the performance tool to check the elapsed time spent in the database executing a report or requesting data from an external system through a connector.

  • If a single query is taking more than 200ms for a for a single query, then there is a potential performance issue. Use the tracer to examine each query executed and identify the queries that are over the threshold. Try to narrow the filter criteria and improve the WHERE clause.
  • If the RDB I/O count is greater than 20, there might be a potential performance issue. Excessive queries to the database may be a sign of an improper query logic or a database schema that has been poorly designed. Check the queries to ensure that they are providing the business value needed. You can reduce repeated queries to the same table by improving the filter criteria of that query.

Guidelines for building a high-performing Pega Sales Automation application[edit]

If you want to build a high-performing application, you must concentrate on the following crucial areas because the way they are set up impacts application performance:

  • Data import
  • User experience
  • Clipboard and data pages
  • Monitor requestors for evaluating clipboard size
  • Integration and connectors

Data import[edit]

Application performance if often impacted by the imported volume of data.  The following are a few recommendations related to data import to avoid degrading application performance:

  • The size of the File Listener based upload should not exceed 1 million records in a single file.
  • Batch size value recommended for upload is 1000 records. Set it up in App Studio > Settings > Application settings.
  • To improve performance and to disable creating audit history, use the Add Only mode for the initial data import.
  • To ensure a maximum parallel processing, there must be as many input files for the file listener as there are threads, because each thread processes one file at the time. Set it up in the File Listener properties in Dev Studio, in the Listener properties section.
  • Database indexes improve query performance; however, when you update a large database table, the system performs re-indexing, which can cause lower performance. Remove non-essential indexes during the import phase. After the import is complete, enable indexing.

For more information about how to improve the application performance while importing data, see  Improve the data import performance by using configuration.

User experience[edit]

How both the user experience and user interface are designed has a large impact on the application performance, both actual and perceived. To avoid poor performance, determine what information is important to display to users. See the following tips:

·        Don't display information until you actually need it. For example, when searching for an object or in landing pages like organization, account, contact, lead, and opportunity only display enough information to identify that object. You can display the remaining part within the work object review harness.

·        If possible, ensure that sections have the defer load option.

·        When showing a list of items, enable progressive loading and set a reasonable page size, for example, 15 items per page.

·        When building the show and hide logic, use expressions instead of When rules because expressions execute on the client-side instead of on the server-side. As a result, expressions perform faster and reduce the server-side load as you scale.

Clipboard and data pages[edit]

There are several factors that are improving the application performance, for example, a clean clipboard on job scheduler requestors, file listener requestors, reasonable overall requestor clipboard size, and efficient and correct load strategies on data pages. A well-designed application provides a continuously responsive performance for job schedulers, file listeners regardless of their shift duration, and it must scale when there are many users per node.

When possible, make data pages requestor-level type to avoid constant reload. The system of record data, data used across cases, and data shared across interactions and service intents are all good candidates to be made requestor-level.

Do not use the Reload once per interaction setting for data pages. This option reloads the data page on every HTTP interaction, instead of once during the interaction  If you need a fine-grain reload strategy, consider using the If older than reload, or the Do not reload when settings, but force the condition to evaluate to ‘true’.

Always select the Clear pages setting after not using pages for read-only requestor-level data pages.

Monitor requestors for evaluating clipboard size[edit]

Monitor requestors periodically for average size to help identify potential issues with loading too many items on the clipboard, pages not being cleared out, and users who do not close.

In Admin Studio, click Users > Requestors > Load requestor size to monitor the clipboard size.

The key items to watch are the average page size of the requestor and the largest page sizes. On average, the requestor size should be 12MB or less across all system users.

Integration and connectors[edit]

Some Pega Sales Automation functionalities integrate with the external systems of record. When integrating with the external systems of record, to ensure high performance, follow these guidelines:

·        Upon receiving connectors, try to independently run load against those connectors by using the industry-available tools, such as JMeter, to understand their performance profile under load.

·        Interfaces should ideally respond in less than 500 milliseconds. Anything that is on average over 1 second should be remediated for performance, independently of integration into your application.

·        Aggregate data sources in data pages to reduce the number of moving pieces required for integration, both for saves and reads.

·        Implementations often use complex and hard to follow activities for performing integrations. The advent of aggregate source data pages removes the complexity.

·        Directly reference connectors and their associated mapping, and if required, add a data transform after your connector sources, to perform any reconciliation or error handling after calling multiple interfaces.


we need an intro sentence here to introduce the section. We can't have a header under header  [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1 [AK1]] [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 1 [AK1]]

How it would be following are some of the areas the need to concentrate to build high performance Pega applications [:File:///C:/Drive D/Work/Pega SA Wiki/Best practices for implementing high performing SA application.docx# msoanchor 2 [KMR2]]

Tools for performance testing[edit]

Performance is an important aspect of any system. The perceived quickness of the system often measures user satisfaction and business value. Pega provides a full suite of tools to monitor and address performance. Use these tools during the development to ensure that your configuration performs optimally.

To open system performance, in the header of Dev Studio, click Configure > System > Performance.

Performance landing page

The Performance landing page provides access to the following performance tools:

·         Performance Analyzer (PAL),

·        Database Trace

·        Performance Profiler.

These tools are also available by clicking the Performance tool in the toolbar. Use the performance tools to collect performance statistics. For more information, see Understanding system resources.

Analyze application performance with PDC[edit]

Pega Predictive Diagnostic Cloud (PDC) is a Software as a Service (SaaS) tool that runs on Pega Cloud® and actively gathers, monitors, and analyzes real-time performance and health indicators from all active Pega Platform™ applications. PDC gathers, aggregates, and analyzes alerts, system health pulses, and guardrail violations generated from Pega applications.

For more information, see  Analyzing application performance through PDC

Analyze application performance with Database Trace[edit]

The Database Trace generates a text file containing the SQL statements, rule cache hit statistics, timings, and other data that reflect the interactions of your requestor session with the Pega Platform database or other relational databases. Familiarity with SQL is not required to interpret the output.

To open the Database Trace, in Dev Studio, click System > Performance > Database Trace. You can also open it from the Performance tool in the toolbar.

For more information, see Analyzing application performance through Database Trace

Analyze application performance with Performance Profiler[edit]

The Performance Profiler is useful when determining which part of the process might be having performance issues, or identifying the particular step of a data transform or activity that might have a performance issue.

When you use the Performance Profiler, you first record readings of the application's performance, then you analyze the readings to identify problems.

To open the Performance Profiler, in Dev Studio, click System > Performance > Performance Profiler. You can also open it from the Performance tool in the toolbar.

For more information, see Analyze application performance through Performance Profiler

Analyze application performance with Performance Analyzer[edit]

The Performance Analyzer (PAL) provides a view to all the performance statistics that Pega Platform™ captures. Use PAL to understand the system resources consumed by processing a single requestor session.

To open PAL, in Dev Studio, click System > Performance or select the Performance tool in the toolbar.

For more information, see Analyzing application performance through Performance Analyzer.

Analyze the logs through PegaRules Log Analyzer (PLA)

Regular monitoring of log files during development and production helps to ensure that your application is operating properly. The PegaRULES Log Analyzer (PLA) is a standalone web application that developers and system administrators use to view summaries of console logs.

Use the PLA to test new or reconfigured Pega applications during user acceptance testing (UAT), performance and stress testing, and immediately after deployment into a production environment.

For more information, see PegaRules Log Analyzer


Summary[edit]

There are several tools that Pega Platform provides to implement high performing applications.   By using these tools you can analyze application performance, debug root causes for the performance decrease, and take necessary steps for further performance improvement.