You
can customize reports to specifically investigate a performance problem in
more detail than what is provided in the default reports.
Setting custom and conditional report colors
Not only can you customize colors in your reports, but
you can also make the report colors change when they match a formula
that you set.
Changing the default appearance of reports
You can change the report default settings for typeface,
color, and graph style of reports, and whether a Compare report automatically
opens when a staged run ends. You can also display a warning when
changing Percentile report options will cause data to be lost.
Customizing the appearance of report graphs
You can change the appearance of a table, bar chart, and
line chart during the current session. To apply the change to all
instances of that report, save the report. You can also change certain
defaults.
Changing the report displayed during a run
Use this page to select the default report that opens during
a run. Typically, you select Determine default report based
on protocols in test, which determines the protocols that
you are testing and automatically opens the appropriate protocol-specific
reports.
Changing information in a report
To gather additional information
for diagnosing performance problems, you can change the information
that appears in a report. You do this by adding or removing report
counters. If you save the changes, the report will contain these updates
the next time that you generate it.
Filtering results
By filtering the results
that are displayed in a report, you can remove unnecessary data and
focus on the data that is significant to you. If you save the changes,
the report will contain these updates the next time that you generate
it.
Evaluating results for a specific time range
After you run a schedule, you can further adjust the time
ranges in a report. The aggregated results are recomputed to take
into account only the data collected during the time range that you
specify.
Creating a custom report
In special situations, if
the default reports do not meet your needs, you might want to create
a custom report.
Correcting time offset
Response time breakdown and
resource monitoring data is time stamped using the system clock of
the host computer. If there are differences between the system clocks
of the host computers that you include in a test, then response time
breakdown and resource monitoring data are skewed in reports. The
best practice is to synchronize the system clocks on all computers
that you include in a test. When this is not possible, you can correct
the time offset of each host computer after a test run. Typically,
correct the time offset on all computers to match the system clock
of the workbench computer.