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.