Overview of the Performance Tools (PAL)
Summary
Process Commander is a powerful enterprise software product which is the base for many different types of applications. These applications can be designed to handle large volumes of work objects and store quantities of data. Poor performance, such as delays encountered in processing, refreshing screens, submitting work objects, or other application functions, can signal that the design of the application or the setup of the server can be improved. It is important to be able to quickly pinpoint the source of such problems.
Process Commander captures information necessary to identify these inefficiencies or excessive use of resources in your application. This data is stored in "PAL counters" or "PAL readings." PAL stands for Performance AnaLyzer, and is a collection of counters and timer readings, stored in the requestor, that an application developer could use to analyze performance issues in a system.
NOTE: The PAL data is generally tracked on the work that is being done by the application. Depending upon the type of application, this work could involve “cases”, insurance forms, credit card forms, or a myriad of other items. Thus, in this document, the generic term “work object” will be used to describe the item being worked on.
NOTE: Another good source for system-wide performance information is the System Management Application (SMA), which is documented in the System Management Application Reference Guide .
IMPORTANT: In Version 5.3, PAL was changed so that only one timer will run at a time – they become “mutually exclusive.”
Prior to 5.3, when (for example) a declarative network was built to run a Declare Expression, the Elapsed Time Executing Declarative Rules might be higher than the Total Request Time, due to the fact that the former included other processing that was also occurring, such as Rule I/O, Other I/O, etc.; the Declarative timer was counting time that was also counted in another timer.
Beginning in Version 5.3, if one timer is going and another is triggered, the first timer will stop (temporarily) so that the time is not double-counted. In the above example, if the Rule I/O timer starts, the Executing Declarative timer will stop until the Rule I/O processing is finished, and then continue tracking the Declarative processing.
NOTE: The only exception to the “mutually exclusive” setup is Total Request Time, which runs no matter what other timers are running.
Quick Links:
Strategies for Testing Performance
Collecting Performance Information from Your Process Commander Application
Best Practice Protocol to Prepare for a PAL Review
Suggested Approach
PAL Usage
PAL is a tool which should be used to gain insight into where the system is spending resources; use PAL to determine if there are resource issues impacting performance, or may begin to do so when more load is added to the system.
PAL readings are not meant to give developers a definitive answer about performance problems. Instead, PAL readings highlight processes which fall outside of the norm. Depending upon how the application is constructed, there may be good reasons why a particular application has readings at a certain level; something which in general might be considered too high a reading might be correct for your application. PAL gives the developer the capability to label and explain these readings, as well as investigate problem readings.
PAL is designed to be used both in test (development) and production environments.
- Use PAL readings in production to troubleshoot problems
- Use PAL readings in development to prevent introducing a problem into a production system, and during the development cycle to catch performance issues early on in the application’s construction
The primary user of PAL is an application developer, who would employ it (as described above) in a development environment. However, other users might include:
Role | Use PAL for |
|---|---|
QA Analysts | Testing – run through a script, and take PAL readings at the beginning and end of the script process to check performance efficiency |
System Administrators | Troubleshooting production systems |
End users | These will be the first people to see problems in production. They can use PAL to gather information about the problems seen in production and forward the data for analysis to the application developer, who may not have access to create the problem in production. |
Strategies for Testing Performance
PAL should be used during all the major steps in the life cycle of an application. It is designed to provide the developer with insight into the performance profile of the application processes that they are building during the time that they are building them. PAL is also designed to be used during the testing stages for QA, as well as for performance and scale testing. Finally, it is available for use in production, to help identify production issues.
NOTE: For most of the business processes, it may be necessary to run through them once before taking PAL readings. The first time any process is being run, Rules Assembly of the Rules used in the process may be occuring, which will skew the performance numbers. PAL readings should always be taken for processes where Rules Assembly has already occurred (since it should only occur once in a properly-designed system). If after the process has been run once, Rules Assembly seems to keep occuring, that would be an issue for further investigation.
Development Strategy
During development, PAL should be used in conjunction with other tools such as DBTrace and the System Management Application to evaluate and project the performance implications of the particular business process under construction.
As a developer begins iteratively creating their business process, they would collect PAL information for every user screen in the process, so that as the process is changed, the developer can see how the performance profile changes, and can therefore quickly identify if a given change has created positive – or negative – performance ramifications. Every time a change is made, a new set of PAL readings would be taken; each set would be saved to compare with the prior and next set.
QA Strategy
PAL is designed to be used in the QA cycle to try to catch performance issues that can be identified during the normal functional testing. Most QA is done by running “scripts” to test the various functional areas of an application; there may be a number of different business processes that different types of users would perform in production. For each of these processes, QA should run their test scripts until no errors occur in the process. Once an error-free test is achieved, then the QA engineer should take a PAL reading, perform the business process end-to-end, take another PAL reading, and review the Detail Screen, to get a sense of the performance implications of that particular business process from start to finish. This sequence should be followed for each business process in the application, to give a perspective of the aggregate performance of the application.
Performance and Scale Testing Strategy
Scale testing should be done to verify that as more users are added to the system, the performance for a specific user does not degrade. This type of testing measures resource contention.
Begin this testing by tracking a single isolated user on the target Process Commander system (i.e., only this user should be using this system right now). As with the QA test strategy above, follow the below steps for this isolated user:
- Identify a specific business process to be tested in the application.
- Before running the process, take a PAL detail reading.
- Run the process end-to-end.
- Take another PAL detail reading.
This will give a performance baseline for this single user in the target hardware environment.
Repeat the above process as additional users are added to the system. For example, at 100 users, run the business process for one of these users and take the same PAL readings; compare these to the baseline readings for the isolated user. For one user in a perfect system, the PAL readings should not change (as the readings are based on one requestor). If the system is well crafted, the number of users should not materially impact the performance profile of the application on an average user basis.
At certain user levels, performance will be affected when resources are not available; at this point, it may be necessary to set the JVM or other system resource levels higher.
Production Strategy
The production model is similar to the QA model:
- Identify a specific business process to be tested in the application.
- Before running the process, take a PAL detail reading.
- Run the process end-to-end.
- Take another PAL detail reading.
Analyze the Detail Screen for these readings.
Collecting Performance Information from your Process Commander Application
Best Practice Protocol to Prepare for a PAL Review
This section details the process of gathering performance data for analysis. This data can then be sent to the application developer for study.
NOTE: It is not necessary to be an application developer to collect this information; Process Commander makes it easy for anyone to run the PAL collection process and track performance.
It is necessary to have a portal that allows the user access to the Tools gadget, in order to take readings; the user must also have the rights to run the workflow being tested.
Determining When to Use PAL
Users
Users should follow this process for collecting PAL data when they determine there is a performance issue. The system may be slow in responding, or system errors (“Out of memory”) may be occuring.
NOTE: To complete this process, users require access to the PAL tool, which is available as the Performance choice from the Run menu.
QA
QA should take PAL readings as an ongoing part of their testing process in the development of a new application. A User Scenario (use case) should be set up, and readings taken as described in the next section. (NOTE: This User Scenario must be realistic – i.e., it must be something that the users of the system would do regularly – or the PAL readings will be meaningless. An example of a common, realistic User Scenario might be Open New Work Object.) QA may discover that, in order to completely test performance for the application, more than one User Scenario must be created.
Taking PAL Readings
Important: Before beginning to take PAL readings, go through the scenario once with no PAL or screen captures being taken. It is necessary to go through the scenario the first time in order to verify that Rules Assembly has occurred on all the Rules being used for the scenario. (Since the Rules need to be assembled the first time a scenario is used, taking PAL readings on this process will give misleading readings on the system efficiency.)
1. Take Baseline Reading
Once the first run-through of the scenario has been completed, open PAL to create the first reading. This will give a baseline from which the actions in the scenario may be measured.
From the Run menu, click Performance. This opens the Performance window, with the PAL Summary statistics.
2. Start Process to be Measured
Begin the process being measured by initiating the first action. In this example, a General Task was opened.
After the first step in the process:
a. Take a PAL reading (click the Add Reading link to add the DELTA)
b. Capture a screenshot of the first screen (make sure to include the entire browser window ) and put it into a document.
3. Continue through every step of the process.
At every step, follow the above procedure:
a. complete the step
b. take a PAL reading
c. take a screenshot
Important: The reading must be taken after the step has fully completed, and all the screens are fully generated.
These screenshots must be taken for every step, for every PAL review that is done. They will be examined by the application developer for consistency between PAL tests, to make sure that the procedures are exactly the same, so the PAL numbers may be valid when compared.
4. Save the data
After all the readings have been made (and all the screen shots taken), click Save Data.
The Save Data link will create a .csv file. Name the file with a meaningful name and save the file. This file may be viewed in Excel:
Send this CSV file and the document with the screen shots to the person doing the PAL analysis.
Additional Resources
The information in this article is taken from the 
Using Performance Tools System Tools paper. This file includes a glossary containing definitions of over 130 PAL counters.For easier searching and viewing, this System Tools paperr has also been published as a series of four linked articles:
- Overview of the Performance Tools (PAL) – (This article)
- Interpreting Performance Tool (PAL) outputs - This section is designed for application developers, and describes the different performance tools in detail. It looks at the specifics of what the PAL readings measure, as well as how to use them to better understand and improve the performance of your application.
- Interpreting the Performance Tool (PAL) Detail display – details on the PAL counters being tracked in the system, and how to interpret the groupings.
- Using the DB Trace and Profiler tools to understand performance – DBTrace helps developers understand the details of the database interactions. (It is easy for database access to become a performance bottleneck – this tool raises the visibility of the database processing.) The Profiler allows users to trace steps within an activity.
Previous topic Interpreting the Performance Tool (PAL) Detail display Next topic Use the V4.2 Profiler tool to monitor performance of an activity