Reading a Performance Measurement Report

The Performance Measurement report consists of the following:

• Overall Performance Chart
• Detailed Performance Statistics Tables
  • Part Statistics – This displays the usage for each part.
  • Node Statistics – This details the usage for each node in the logicnets of the application.
  • Logicnet Statistics – This shows the usage of each logicnet.
  • Request Statistics – This shows the details for each request for the individual tokens in the application.
  • Session_load Statistics – This shows the details of the session load function for each token.
  • Session_save Statistics – This shows the usage information for session save for each token.

Overall Performance Chart

In the Overall Performance chart users can see how long each part of the application took to run. The horizontal lines show time duration.

 
Vertical lines in the chart show the following:

• Flags – Flags calls set by the user
• Session_save – Session save function calls
• Part – Overall part calls
• Node – Overall node calls in each logicnet
• Logicnet – Overall logicnet calls
• Session_load – Session load function calls
• Request – Requests sent from the browser to server (this does not include http header and network traffic.

Detailed Performance Statistics Tables

There is also a table of detailed performance statistics in the report, including the following:

• Total – Total amount of time
• Mean – Average of all numbers
• Stdev – Standard deviation, which shows how much the single number differs from the mean value for the group
• Count – Total number of calls

Suggested Approach to Performance Management

The performance report can be used in a variety of ways to pinpoint the performance "hotspots" or weakpoints in your application.

Look at the overall chart to see the total elapsed time from request to result, and begin to drill down to logicnets, then nodes to see the biggest time sinks.

The table of node and part times is useful to see how "expensive" different processes are. Note that a single occurrence of an expensive part may impact your system performance less than a larger number of less expensive parts. Oftentimes there is no obvious alternative approach to modelling, but pay particular attention to reading in data from tables - the execute query, get records, and query collection parts can each do this and are more interchangeable in some ways, and have different performance footprints.

Other Factors

Don't forget there are a variety of other factors that impact performance, not just the logic flows modelled in the Designer. These factors include:

• number of concurrent users
• nature of user tasks (few infrequent clicks in a text-heavy application, vs large data processing app)
• server specification (number of CPUs, RAM, etc.)
• stability and size of network and other traffic on that network