Debugging & Managing system performance

Which feature in Pega Platform allows you to measure the overall quality of an application's design?

If you are a Cloud Customer, what is the best way for you to set a performance threshold?

In which two ways can you identify rule caching performance issues? (Choose Two)

Which three actions can you take to minimize the number of ruleset lists in use in an application? (Choose Three)

Which two of the following statements about large tables in Pega Platform are true? (Choose Two)

Which performance tool do you run to determine which specific step executed by your requestor session that is causing a problem?

Which two types of issues are identified by using Pega Platform alerts? (Choose Two)

Which two approaches reduce the possibility of rule caching causing performance issues in your application? (Choose Two)

Which performance tool do you run to examine a query made to the database?

Which of the following options can you use along with system alerts to determine if your application performance needs optimization?

Use "pega", "alert", or "alertsecurity": A node was shut down for an update: [blank_start]PEGA[blank_end] A database query exceeded the performance threshold: [blank_start]ALERT[blank_end] A login attempt failed due to an incorrect password: [blank_start]ALERTSECURITY[blank_end] An attempt to access a third-party service failed due to an incorrect user name: [blank_start]PEGA[blank_end]

A SECU0006 alert is generated with the message PRPC detected excessive failed login attempts for the user:XXXX from IP:192.168.100.100. Brute force attack prevention measures were invoked. What three pieces of information do the alert ID and message provide? (Choose Three)

The logging level identifies the severity of the issue. [blank_start]FATAL[blank_end]: Severe errors that can cause the application to terminate. [blank_start]ERROR[blank_end]: Serious errors that might allow the application to continue running. [blank_start]ALERT[blank_end]: Performance-related issues, such as an exceeded performance threshold, or an event that affects performance, have occurred. [blank_start]WARN[blank_end]: Potential issues that might cause an adverse performance result. [blank_start]INFO[blank_end]: Notifications of runtime events, such as system startup or shutdown. [blank_start]DEBUG[blank_end]: Informational events that are useful for debugging.

The [blank_start]PegaRULES Log Analyzer (PLA)[blank_end] is a standalone web application that developers and system administrators can use to view consolidated summaries of system log data. The [....] consolidates and summarizes the ALERT, PEGA, and Garbage Collection (GC) logs. The log data provides key information about operational and system health that developers and system administrators can use to quickly identify, diagnose, and address performance issues.

The [blank_start]PegaRULES Log Analyzer (PLA)[blank_end] is a [blank_start]standalone web application[blank_end] that developers and system administrators can use to view [blank_start]consolidated summaries of system log[blank_end] data. The [....] consolidates and summarizes the [blank_start]ALERT, PEGA, and Garbage Collection (GC)[blank_end] logs. The log data provides key information about operational and system health that developers and system administrators can use to quickly [blank_start]identify, diagnose, and address[blank_end] performance issues.

Log files capture [blank_start]event notifications[blank_end] ranging from [blank_start]routine system status information[blank_end] to [blank_start]severe errors[blank_end] that can cause [blank_start]an application to quit unexpectedly[blank_end]. Each log is managed by an [blank_start]appender[blank_end], which determines the type of events written to the log file. The available log files vary, depending on the [blank_start]log file appenders[blank_end] that are configured in the [blank_start]system settings[blank_end]. The following log files are commonly used on Pega Platform systems: The [blank_start]PEGA[blank_end] log contains warnings, errors, and information messages about internal operations. This log is also called the console log or system log and is used for debugging the application. The [blank_start]ALERT[blank_end] log contains performance-related alerts triggered when an operation exceeds the specified performance threshold. The [blank_start]ALERTSECURITY[blank_end] log contains alerts (identified by the prefix SECU) that suggest improper configuration of Internet Application Composer facilities, or overt attempts to bypass system security features on the Pega Platform node through URL tampering. The [blank_start]BIX[blank_end] log contains entries generated by the Business Intelligence Exchange (BIX) during extract operations. The [blank_start]SERVICES-PAL[blank_end] log contains performance data saved from services. The [blank_start]CLUSTER[blank_end] log contains information about the setup and run-time behavior of the cluster. Note: Pega Platform manages logs based on [blank_start]which appenders are configured[blank_end]. For example, to log performance data for services, you add [blank_start]SERVICES-PAL in the prlog4j2.xml[blank_end] configuration file for the node. You access log files from the [blank_start]Log utilities section of the Logs tab[blank_end] in Dev Studio. The Log utilities section includes a list of log file [blank_start]appenders and an external log viewer[blank_end]. Clicking Log files displays a list of the log file appenders that are [blank_start]active on the system[blank_end]. Downloading a log file requires [blank_start]administrator credentials[blank_end] for the application server that hosts Pega Platform. You can also view log files using an external log viewer, such as [blank_start]Kibana[blank_end]. A system administrator can [blank_start]override log level settings[blank_end] in [blank_start]Admin Studio[blank_end] to control which logging events are displayed in the PEGA log by creating a [blank_start]log category[blank_end]. Events are recorded only for the [blank_start]selected logging level and higher[blank_end]. When debugging an activity, you can use the [blank_start]Log-Message method[blank_end] with the logging level set to [blank_start]InfoForced[blank_end] to add an event to the PEGA log regardless of settings in the [blank_start]prlog4j2.xml file or the Log Category[blank_end]. To reduce log entries and improve performance in production systems, remove InfoForced steps or convert them to comments when you finish debugging the activity.

As a Pega Cloud client, you can download log files from the [blank_start]My Pega Cloud portal[blank_end] for internal analysis or to share with [blank_start]Pegasystems Global Client Support (GCS)[blank_end]. From the My Pega Cloud tab, you can download a [blank_start]bundle of specified log files[blank_end] created from your environment during the [blank_start]last 365 days[blank_end]. Each download you complete using the My Pega Cloud portal supports [blank_start]up to seven days of logs[blank_end]; to download more additional logs, you [blank_start]must initiate a separate request[blank_end] for the additional day's logs. The log bundle is a [blank_start]compressed TAR file[blank_end] you can download to your local computer. At run time, the Pega [blank_start]generates alerts[blank_end] for [blank_start]performance and security-related[blank_end] application issues. Alerts are [blank_start]text-based messages[blank_end] that serve as important notifications about the [blank_start]functioning of your system[blank_end]. [blank_start]Performance alerts[blank_end] are generated when rule execution exceeds a [blank_start]performance threshold[blank_end]. [blank_start]Security alerts[blank_end] are generated when the security of a [blank_start]Pega Platform server is at risk[blank_end]. Analyze alerts to identify the root cause of a performance or security issue. You can access alerts from your session from the [blank_start]My Alerts display[blank_end]. The alert format provides information about the alert. You can determine whether the alert is [blank_start]performance or security[blank_end] related, the [blank_start]type of alert[blank_end], the [blank_start]type of requestor[blank_end] (for example, a browser), and [blank_start]the activity or stream[blank_end] that triggered the alert from the alert format. The most frequently-generated alert is the [blank_start]PEGA0001[blank_end] alert, which occurs when the elapsed time for an HTTP interaction time exceeds the threshold setting. The [blank_start]SECU0005[blank_end] alert is generated when Pega Platform encounters a thread name in the [blank_start]URL of an HTTP request[blank_end] that [blank_start]does not already exist in the requestor[blank_end] and whose name contains [blank_start]invalid characters[blank_end]. This alert allows you to identify potentially malicious scripts that have been inserted into the thread name portion of the URL so that you can research and [blank_start]correct the thread name[blank_end] or other issues as appropriate.

Used to understand the system resources consumed by processing a single requestor session: [blank_start]Performance Analyzer (PAL)[blank_end] Used to tune the application in case of any database performance issues: [blank_start]Database Trace[blank_end] Used to get a detailed trace of performance information about the execution of activities, when rules, and data transforms executed by your requestor session: [blank_start]Performance Profiler[blank_end] Used to actively gather, monitor, and analyze real-time performance and health indicators from all active Pega applications: [blank_start]Pega Predictive Diagnostic Cloud[blank_end]

A developer collects baseline readings for a flow action in the system via Performance Analyzer. A change for the same flow actions comes later in the sprint. The developer collects the Performance Analyzer readings again for that flow action. What might the comparison of the new and previous readings suggest?

DB Trace is best suited to diagnose a performance issue in which two of the following environments? (Choose Two)

Which two statements about the Database Trace are true? (Choose Two)

The Performance Profiler is used to identify a step of a data transform that might have a performance issue.

Which two metrics does the Performance Profiler tool measure? (Choose Two)

Which two of the following elements does PDC monitor? (Choose Two)

Which statement about PDC is true?

As you run a case instance, you notice it takes a significant amount of time to advance from one view to the next view. You run the case multiple times and notice the same slow performance. How do you proceed?

The reason you want to run a process immediately before you take performance readings is ____________.

In which scenario is it most appropriate to leverage Predictive Diagnostic Cloud?

Which performance tool do you use to collect performance data for individual steps in a data transform?

The [blank_start]Performance landing page[blank_end] provides access to the three performance tools: Performance Analyzer (PAL), Database Trace, and Performance Profiler. These tools are also available from the [blank_start]Performance tool in the toolbar[blank_end]. Performance statistics can help you distinguish between [blank_start]performance issues[blank_end] that arise in the [blank_start]Pega Platform server, the database[blank_end], [blank_start]or external systems called[blank_end]. In all cases, the statistics can help you determine how to improve performance. [blank_start]Performance Analyzer (PAL)[blank_end]: Pega always gathers cumulative resource statistics. Use this tool to understand the system resources consumed by processing a single requestor session. It works on existing data; it does not degrade processing. [blank_start]Database Trace[blank_end]: This tool is useful to tune the application in case of any database performance issues. [blank_start]Performance Profiler[blank_end]: Use this to obtain a detailed trace of performance information about the execution of activities, when condition rules, and data transforms executed by your requestor session.

Performance Analyzer (PAL) The first step to measuring your application performance is to [blank_start]take measurements[blank_end]. Start by clicking [blank_start]Reset Data[blank_end] to clear any data in the tool. Because the system continuously monitors performance, you are [blank_start]eliminating any previously recorded[blank_end] entries from your results by resetting data. There are two options for adding a reading: [blank_start]Add Reading[blank_end] and [blank_start]Add Reading with Clipboard Size[blank_end]. The only difference between the two readings is the clipboard size, which [blank_start]takes extra time to calculate[blank_end]. When adding a reading, the best practice is to [blank_start]define points[blank_end] that identify [blank_start]what occurred during that reading[blank_end]. For example, use one reading [blank_start]per flow action[blank_end] or [blank_start]screen render[blank_end], depending on what process you are measuring. You can download the results to an Excel file by clicking [blank_start]Save Data[blank_end]. The [blank_start]INIT[blank_end] row displays the totals from [blank_start]the first time[blank_end] the Performance tool made a reading. This bottom row shows the totals since the [blank_start]first intitialzation[blank_end] of the Performance tool. Most readings in this row at the outset are [blank_start]near zero[blank_end]. If the readings are [blank_start]not near zero[blank_end], click Reset Data to reset the readings. Each subsequent reading is labeled as a [blank_start]DELTA[blank_end], which indicates the [blank_start]change from a previous reading[blank_end]. Delta rows are displayed as you [blank_start]interact with Pega Platform[blank_end]. Each row shows values that [blank_start]accumulated[blank_end] from the [blank_start]previous Delta or Init row[blank_end]. The [blank_start]FULL[blank_end] reading reflects the [blank_start]totals[blank_end] since [blank_start]that start of your session[blank_end] [blank_start]or the most recent Reset Data operation[blank_end]. Clicking INIT, DELTA, or FULL displays more details about the reading. Many different results are available to you for analyzing the performance. Be mindful of [blank_start]first use assembly (FUA)[blank_end], as it can skew initial readings. To obtain results unaffected by FUA, run through the process once to ensure that [blank_start]all rules are assembled[blank_end] before taking any measurements. [blank_start]Int #[blank_end]: Sequence number of the most recent completed interaction. [blank_start]Int Count[blank_end]: Total number of interactions. [blank_start]Total Elapsed[blank_end]: Total elapsed time for this interaction. [blank_start]RA Elapsed[blank_end]: Rules assembly elapsed time. [blank_start]Rule I/O Elapsed[blank_end]: Elapsed time spent finding rules. [blank_start]RDB I/O Elapsed[blank_end]: Elapsed time executing SQL operations against the PegaRULES database; [blank_start]excludes Connect SQL executions[blank_end] for the PegaRULES database or external databases. [blank_start]Connect Elapsed[blank_end]: Time spent waiting for an Connect rule execution [blank_start]to an external system[blank_end]. [blank_start]Other I/O Elapsed[blank_end]: Elapsed time accessing [blank_start]non-rule-resolved[blank_end] instances from the PegaRULES database plus the elapsed time [blank_start]retrieving non-rule database lists[blank_end]. [blank_start]Total CPU[blank_end]: Total CPU time used. [blank_start]RA CPU[blank_end]: CPU time spent assembling Java classes.

Database Trace Run Database Trace if [blank_start]PAL readings[blank_end] indicate performance issues in the [blank_start]database operations[blank_end]. Database Trace can trace [blank_start]all the SQL operations[blank_end] like [blank_start]queries or commits[blank_end] that are performed. The Database Trace produces a [blank_start]text file[blank_end] containing [blank_start]the SQL statements,[blank_end] [blank_start]rule cache hit statistics, timings, and[blank_end] [blank_start]other data that reflect the interactions[blank_end] of your requestor session with the [blank_start]Pega database[blank_end] or [blank_start]other relational databases[blank_end]. A basic familiarity of SQL Operations, (for example read, write, and insert), and BLOB is useful to interpret the output. Downloaded data contains a [blank_start]sequential progression[blank_end] of trace events. Operating the Database Trace tool can [blank_start]adversely affect performance[blank_end] by producing a large volume output. Use the tool for [blank_start]short periods[blank_end], in [blank_start]non-production environments[blank_end] appropriate for debugging. Click [blank_start]Trace Options[blank_end] to open the settings window. The settings window lists [blank_start]all possible events[blank_end] to trace. If an event is [blank_start]inapplicable to a situation[blank_end], remove it from the list to streamline the results. You also have the option to [blank_start]generate a stack trace[blank_end]. Generating the stack trace is an [blank_start]expensive[blank_end] process and should only be used when required.

Performance Profiler Use the Profiler to obtain a [blank_start]detailed trace[blank_end] of performance information about the execution of [blank_start]activities, when condition rules[blank_end], and [blank_start]data transforms executed[blank_end] by [blank_start]your requestor session[blank_end]. The Profiler traces [blank_start]every execution (in all Threads)[blank_end] of rules of [blank_start]these three types[blank_end] in [blank_start]all rulesets[blank_end]. The Performance Profiler should be run in conjunction with [blank_start]Performance Analyzer[blank_end] to narrow down the specific step of the cause. When you use the Performance Profiler, you [blank_start]first record readings[blank_end] of the application's performance, and then you [blank_start]analyze the readings[blank_end] to identify problems. The Performance Profiler requires [blank_start]substantial processing overhead[blank_end]. Stop the Performance Profiler as soon as your data collection is complete. In the Performance Profiler results table, click the Download icon to save the results in a [blank_start]comma-separated value file format[blank_end]. The results can then be opened by using any spreadsheet program, such as Excel, to review the Performance Profiler readings. [blank_start]Sequence[blank_end]: Marks the beginning of each activity step or other row. [blank_start]Interaction[blank_end]: Sequence number of the interaction, as recorded in the Performance tool. Starts with 1 on the initial display of the login form. [blank_start]Activity[blank_end]: Handle of the activity, when condition, or data transform. [blank_start]Caller[blank_end]: Handle of the activity that called the current rule. [blank_start]Step[blank_end]: Step number. For when condition rules, this value is always [blank_start]W[blank_end]. For data transforms, this value is always [blank_start]M[blank_end]. [blank_start]Method Name or When Result[blank_end]: For activities, [blank_start]identifies the method in the step[blank_end]. For when condition rules, [blank_start]displays true or false[blank_end]. For data transforms, [blank_start]this value is blank[blank_end]. [blank_start]Total CPU time[blank_end]: Total CPU time in seconds for this step. If this step contains a [blank_start]Call or Java instruction[blank_end], the CPU time of [blank_start]called activities is included[blank_end]. [blank_start]CPU Time Without Children[blank_end]: Total CPU time in seconds for this step, excluding time for called processing. If this step contains a Call or Java instruction, the CPU time of [blank_start]called activities is not included[blank_end]. [blank_start]Total Wall Time[blank_end]: Elapsed time in seconds to complete this step. Values reflect the impact of other users on this server, waits for database operations and external events, and so on. [blank_start]Wall Time Without Children[blank_end]: Elapsed time (wall time) in seconds, for this step, [blank_start]exclusive of any called processing[blank_end]. (This value is useful for isolating the performance of [blank_start]Java steps[blank_end] that may perform extensive processing in addition to calling activities.)

Pega Predictive Diagnostic Cloud The PDC is a Software as a Service (SaaS) tool that runs on Pega Cloud and actively [blank_start]gathers, aggregates, monitors[blank_end], [blank_start]and analyzes real-time performance[blank_end] and [blank_start]health indicators[blank_end] from [blank_start]all active Pega applications[blank_end] such as alerts and guardrail violations. PDC allows you to monitor [blank_start]several on-premise and cloud-based[blank_end] Pega applications. Pega sends [blank_start]known and safe content[blank_end] to PDC by using only the clipboard parameter data that is [blank_start]required for analysis[blank_end]. The data is sent [blank_start]asynchronously[blank_end] to minimize any performance impact on the monitored Pega implementation. Data with [blank_start]identifying information[blank_end] is not sent due to privacy concerns, and PDC [blank_start]does not request information[blank_end] from the monitored application. Pega gathers the following data for PDC: [blank_start]Alerts[blank_end]: Identifies the type of alert and the metadata captured in an interaction. [blank_start]Parameter page[blank_end]: Describes the parameters from the current parameter page, including important contextual information about the functions that run in the monitored application. All remaining parameters are filtered out and excluded. [blank_start]Database alerts[blank_end]: Details the database query, excluding business data values. [blank_start]Exceptions[blank_end]: Contains some contextual data that is a subset of the fields sent for alerts. [blank_start]Performance statistics[blank_end]: Includes statistics for average response time and unique user count. PDC uses these statistics to identify overall performance and performance trends for monitored applications. [blank_start]Database indexes[blank_end]: Includes database index information. PDC uses database index information to generate recommendations to improve query performance. PDC [blank_start]analyzes and aggregates[blank_end] the data generated from Pega applications to produce [blank_start]trending dashboards (graphs)[blank_end]. The trending dashboards provide a [blank_start]graphical representation[blank_end] of daily [blank_start]average response usage[blank_end], [blank_start]interaction volume, and[blank_end] [blank_start]user sessions counts[blank_end]. The presentation of data in [blank_start]trend graphs[blank_end] helps to [blank_start]monitor, isolate and identify[blank_end] [blank_start]and anticipate issues[blank_end] by presenting behavior over time. PDC empowers [blank_start]business stakeholders[blank_end] and IT administrators to take preventative action by predicting potential system performance and business logic issues and providing remediation suggestions. Use [blank_start]Improvement Plan[blank_end] to view a summary of issues that affect the performance of your monitored system. Use [blank_start]Event Viewer[blank_end] to conduct an in-depth investigation. Pega Predictive Diagnostic Cloud generates [blank_start]notifications[blank_end] that you can receive as messages to help you address any issues that might occur. By default, PDC sends notifications by email. However you can configure PDC to send individual notifications by [blank_start]SMS, notification API, or to ServiceNow[blank_end].