This presentation is part of the Designing and Building for Performance Self-Study Course.

Transcript

Hidden performance issues might include run times or resources used that are not high enough to trigger an alert, but that are still high enough to indicate that more system resources are being used than expected.

We will address these issues using the Performance Analyzer (PAL)

Before doing anything, click the Reset Data link twice to initialize the PAL readings to zero.  After each screen, click the Add Reading link to obtain a DELTA reading for each. The PAL readings for each screen in the flow provide a story.  The summary view enables you to quickly identify spots where significant performance spikes occur in a process.

Note:  Reset and re-do the readings if significant values for the "RA" columns (representing rules assembly) are shown.  Rules assembly skews the results significantly, and PAL should be analyzed only after rules assembly has occurred.  If rules assembly persists, work with the system administrator to determine if there is a configuration issue with PRPC.

Understanding PAL int Count Values

The "Int Count" value shows how many times the browser communicated with the PRPC for this request.  Typical screens take from 1 – 3 interactions.  Complex screens with a lot of dynamic content may show this number much higher.  The more interactions per request, the more overall network latency will build up.  This view shows  how much total time it took screen to screen and how the time was spent (i.e., which categories it falls into).

Understanding PAL CPU Time Values

CPU time can indicate if the process is a computationally intensive one.  For example, a screen that used 0.18 seconds of CPU would mean that in a single user development environment that the "Total Elapsed" response time would be sub-seconds.  However, remember this one screen is using 1/5th of the total CPU on the machine.   In a production system this does not leave much capacity for more than 4 or 5 more concurrent users.  When comparing the "Total CPU" time to the "Total Elapsed" time, the developer can understand how CPU bound that request was.  If the Total Elapsed is 0.20 seconds and Total CPU is 0.18 seconds, then that request was almost all CPU.  CPU numbers are not available for UNIX based systems, which is why it is important for the installation to have one Windows-based machine available for PAL analysis during development and testing.

Understanding PAL Rule Count Values

Rule Counts provide insight into the number of rules being executed between readings. Are they in line with the number of rules you have coded or are they 10x, 100x or more?  Very high Activity counts can be very useful in identifying poor performing looping conditions in the process or excessive procedural execution.  High Connect counts give you an idea as to how "chatty" your logic is with the back end systems.  Five or 10+ connector calls per request could add up quickly to long overall response times.

Understanding PAL Total Byte Values

The Total Bytes counter indicates how much data is moving between the client and the server. This counter helps determine if there are very heavy screens or if large amounts of data are being sent to the server.  Numbers of 100k or more certainly are worth looking into as they will surely strain the network and the browser machine to process all that HTML and data.

Understanding the PAL Detail Screen

Click the link under one of the DELTA readings that requires further understanding, possibly due to a long Total Elapsed or a high Total bytes, to see over 100 different PAL statistics presented. 

Do not be intimidated by the list of numbers, as there are a few here that are of particular interest, while the other more esoteric values can be researched if you need it at a later time.

In the Database Access Counts section, search for any that happen to have the term "Storage Stream" in the label.  These pertain to measurements related to reading or writing the BLOB or pzPvStream to/from the database.  These can be particularly resource intensive. 

Scanning over all the PAL detailed statistics, any value that seems to be particularly high may be worth inspecting in more detail.