In Rational® Performance Tester, a schedule is a way of simulating load when testing an application. A schedule can be set up to run multiple instances of a test or to run multiple tests, all at once, to simulate the effect of having multiple end users using the application simultaneously. For information about setting up tests and schedules with Rational Performance Tester, see Creating tests and Representing Workloads.
Prerequisites:
First, you must specify that your tests and schedule should generate the ARM monitoring data that will be collected and analyzed:
Next, to collect performance data for an application running under the schedule, create a new profiling configuration, with the following specifics:
Tip: If you do not want to change any of the default settings for the profiling configuration (all component, no filters, no sampling), you can simply right-click on the schedule and select Profile > J2EE Application with Performance Schedule, instead of the above steps.
Note 1: Unlike in other data collection scenarios, when you click Profile for a J2EE Application with Performance Schedule configuration, both monitoring and the schedule are automatically started so that data collection is synchronized with the schedule starting.
Note 2: If you monitor a subset of users, it is possible that the schedule will appear to exercise a subset of the hosts involved in the application. Data will be collected only from those hosts that are exercised by the subset of users. This may result in what appears to be missing data from other hosts (hosts that were exercised by the non-monitored users). There is no way to control which specific users are monitored.
Note 3: Filters and samples work on root transactions. For collecting data from schedules, the root transaction takes place on the first ARM-instrumented element to be run. If the entire schedule is ARM-instrumented (that is, the Enable ARM Instrumentation check box is selected for the top-level schedule element), there will only be one root transaction, and so filtering and sampling will be ineffectual.
When the schedule has finished running, the test results and profiling data are available in the locations specified in the profiling configuration. Only data generated by the schedule is included in the results. Any other activity on the Web application is filtered out and not included in the performance data collected. For example, if other people are using the application at the same time that the schedule is running, the collected data does not include data resulting from their actions.
Once you have collected the performance data, you can begin analyzing it and diagnosing the problem. You can view the data using several views including statistics views and sequence diagrams of class and object interactions.
Related concepts
Distributed performance and problem analysis tools overview
Related tasks
Creating a profiling configuration for runtime problem determination