Performance Analysis

The Performance Analysis tools provide a number of useful screens, enabling administrators to analyze STEP events, activity, and results of the scheduled health checks. Only the health checks that are relevant to customers and provide actionable information to help improve system performance are included in the scheduled health checks. Some functions available within the admin portal are useful only for Stibo Systems Technical Support and/or R&D groups, while others are applicable for any system administrators.

  • Monitor performance trends for opportunities to improve system performance.

  • Identify whether business rule logic, data objects, and/or event handling are contributing to poor system performance.

  • Troubleshoot cases where a performance impact has been observed.

The Performance Analysis tools can be accessed via the Performance Analysis link found on the Resources section of the Start Page. This separate user interface contains three analysis tools: Health checks, Activity tree, and Events. Using the 'Health checks' screen, in conjunction with the 'Activity tree' and Events graph, can help to identify slow-running processes and correlate issues with event queue activity to identify whether business rule logic, data objects, and/or event handling are contributing to poor system performance.

For a list of health checks that are scheduled to run, refer to the Healthcheck Test Index topic in the Administration Portal documentation.

Setup Requirements

The configuration properties associated with the Performance Analysis tools are:

  • HealthCheckScheduler.AutoRun

    • Allows the user to disable, enable, or skip the automated execution until a date in the future.

    • Possible values are 'true,' 'false,' and a date specified by the user.

  • Note: When a future date is specified, the schedule does not run until that date. Once the specified date has passed, the schedule is enabled.

  • HealthCheckScheduler.OperatingDayAndHours

    • Allows the user to schedule the start day(s) of the week, with possible values of: sun, mon, tue, wed, thu, fri, sat

    • Allows the user to schedule the start and end time of scheduled health checks, with possible values for the window of: [0-9][0-9];[0-9][0-9]

      Example: sat 4-8 means that the scheduled health check analysis begins on Saturdays at 4 a.m. with the list of pre-defined health checks and stops new executions at 8 a.m. Ideally, the window size is large enough to run the scheduled health checks during that period of time.

Once the configuration proprieties have been set, the scheduled health checks can be monitored via the Performance Analysis tools. To access the Performance Analysis tools, refer to the Accessing Performance Analysis Tools topic.

Available Tool Options

Each of the performance tools is defined in the Performance Analysis Tools topic.

Performance Analysis Tools Example

This is an example of how an administrator might benefit from Performance Analysis tools.

Consider that a system is configured to trigger an Event Processor executing a business action following the import of products, which triggers an Outbound Integration Endpoint, sending the changes to a downstream system. This flow can quickly create a high volume of events in the system, assuming the import volume is high.

The Events graph shows the rate of event creation on one line and the rate of event consumption on another line of the same graph, which shows how well the system is able to process changes. A minor phase-shift is typical between creation and consumption of events, based on schedules and execution time of the business action.

In this example, we assume the action takes more than a few seconds to execute. This could be because:

  • the action is written inefficiently

  • the action encounters objects that have a lot of children or references or values or revisions

  • there are time delays while concurrent updates to the same object in a different transaction are retried

  • or other issues.

In any of these cases, the consumption of events lags behind the creation significantly. When this occurs, the weekly executed health checks indicate issues, detailing which objects, the number of occurrences, timestamps, and the related BGP ID.

Using the information from the health checks and lag in event processing, the 'Activity tree' screen is useful to drill into an identified time frame to help indicate the configuration areas where the system is spending the most time. Exploring the 'Activity tree' for the highest percentages below the Event Processors exposes the ID of the problematic Event Processor, the BGP ID, the ID of the Business Action and the lines of code where the system is spending the most amount of time.

By combining the information in these screens, the administrator is empowered to quickly identify the contributors to performance issues, continue to research, modify and test to resolve the identified issues, which may involve rewriting a business action, adding an Event Processor to manage revisions, restructuring hierarchies, or other configurations changes, in order to optimize the system performance.