Schedule properties

Schedule properties

+
Search Tips | Advanced Search

User Load page

Right-click in the table, and select Add to add a stage.

To modify a stage, select the row, and then click Edit or click the user icon in the first column.

Users Total number of users to be active in the stage (not the number of users to add or subtract to those currently running).
Run for specified period of time Length of time (and the time units) for the stage to run. When the number of Users is achieved, the users will run for up to this time. When the time expires, the users continue to run if they are needed for the next stage; otherwise, they are stopped gracefully.

Click Show Advanced to set further options to prepare the system under test before the users actually enter the stage:

Change Rate Set a delay between adding or removing each user, rather than adding them or subtracting them all at once.
Staggering users avoids overloading the system, which can cause connection timeouts. The User Load Preview shows this time in black.

Settle Time A system under test might react to a sudden change in user population. With a defined settle time, which starts when the target number of users is reached, the system under test can settle into a steady state so that it can accurately reflect the user population. The User Load Preview shows this time in black.
Time limit for a user to respond to a stop request Optionally enter a value. When a virtual user is asked to stop, it completes its current action (such as an HTTP request) and then finishes. If a virtual user has not finished within the time limit specified, the user is forced to finish.
User Load Preview Previews the user population stages over time. The red line segments indicate that the total number of users has been achieved for the state.

Think Time page

Use the recorded think time Play back a test at the same rate that it was recorded. This option has no effect on the think time.
Specify a fixed think time Each user's think time is exactly the same value: the value that you specify. Although this does not emulate users accurately, it is useful to play a test back quickly.
Increase/decrease the think time by a percentage Type a percentage in the Think time scale. Each user's think time is multiplied by that percentage. A value of 100 causes no change in think times. A value of 200 doubles the think times, so the schedule plays back half as fast as it was recorded. A value of 50 reduces the think times by half, so the schedule plays back twice as fast. A value of 0 indicates no delays.
Vary the think time by a random percentage Each user's think time is randomly generated within the upper and lower bounds of the percentages that you supply. The percentage is based on the recorded think time.
For example, if you select a Lower limit of 10 and an Upper limit of 90, the think times will be between 10 percent and 90 percent of the original recorded think time. The random time is uniformly distributed within this range.
Maximum think time Set a maximum think time is useful with tests that emulate actual think times. By setting a maximum, you do not have to search for and edit each long think time within a test. Numerous factors can generate long think times, for example, you might be interrupted while recording.
To restore the original think times, clear this box.

Resource Monitoring page

Enable resource monitoring Available data sources are captured from...

IBM Tivoli monitoring agents
IBM DB2 snapshot monitors
IBM WebSphere Performance Monitoring Infrastructure
JBoss Application Server Managed Beans
Oracle WebLogic Server Managed Beans
SAP NetWeaver Managed Beans
UNIX rstatd monitor
Windows Performance Monitor

Ignore invalid resources when executing the schedule Suppress error messages that invalid resources cause, such as unreachable hosts or invalid host names. View logs to see error messages.

Statistics page

Statistics log level These options are listed in order of the increasing amount of data that they collect for the test log.

None Collect minimal statistical data. Use to run through a schedule quickly for testing purposes.
Schedule Actions Report the number of active and completed users in the run.
Primary Test Actions
For HTTP tests, report page-related actions (attempts, hits, and verification points).
For SAP tests, report information on SAP screens.
Secondary Test Actions For HTTP tests, report information that is related to page elements. This option does not apply to SAP tests.
All Provide statistics for all actions.

Statistics sample interval Set the sampling interval for reports.
When you run a schedule, the reports show such information as...

Response time during a specific interval
Frequency of requests being transferred during an interval
The average response trend during an interval

For long-running tests, to avoid issues, set a larger sampling interval.
Only store All Hosts statistics Select unless you are running a performance test over different WANs and you are interested in seeing the data from each remote computer.

Performance Requirements page

Enable Performance Requirements Enable the use of performance requirements for this schedule.
Name Name of this set of performance requirements. Used in the Performance Requirements report. By default, the name is...
Performance Schedule - "Schedule_name"

Use Defaults Click to reset Name to the default value.
Performance Requirement All performance requirements are displayed in the table. Shaded requirements are not defined for this schedule.
To define a requirement, set an Operator and Value.
Operator Display a list of mathematical operators. Select an operator for this performance requirement.
Value Set a value for the requirement.
Standard If a standard requirement is not met, the schedule run will have a verdict of fail, and this verdict will roll up to the entire run, like a verification point failure. Clear to make the requirement supplemental.
In general, supplemental requirements are those that are tracked internally. A supplemental requirement cannot cause a run to fail, and its results are restricted to one page of the Performance Requirements report.
Hide Undefined Requirements See only the requirements that you have defined. This hides the shaded rows.
Clear Select one or more requirements and click to remove the definition. The requirement is still available and can be redefined.

After run completes, if any performance requirements have failed during the run, a message is written to the Performance Report Run Summary page.

Test Log page

The default setting is to log all errors and warnings and primary test actions.

You can log any type of information, from no information to all information from all users, although neither is a typical situation.

To see only errors and warnings...

Set the first two What to Log check boxes to All
Clear the third check box "And also show all other types"

To check the structure of a schedule, when you are not interested in the test execution results, set all three What to Log boxes to Schedule Actions.

Both choices and the default setting limit the size of the test log and reduce the total time to run the schedule by shortening the test log transfer time at the end of a test.

If you are debugging a test, you might set all three What to Log fields to All or Action Details. These settings produce large test logs, especially if tests are long or you are running a large number of users. Large test logs, in turn, increase the test log transfer time, and might even cause computer to run out of disk.
To reduce transfer times and the likelihood of running out of disk, sample information from a very small subset of users; smaller even than the default of 5 users per user group. A fixed sampling rate samples the same number of virtual users from each group. A percentage sampling rate samples a percentage of virtual users from each group, but guarantees that at least one user is sampled from a group.

Response Time Breakdown page

Enable collection of response time data Activate response time breakdown for each page element.
Detail level Select Low or Medium to limit the amount of data collected.
Only sample information from a subset of users If set the detail level to High or Medium, set a sampling rate to prevent the log from getting too large.
Fixed number of users Number that you select is sampled from each user group.
Unless you have specific reasons to collect data from multiple users, select...
Fixed number of users

...and specify one user per user group.
Percentage of users Percentage that you select is sampled from each user group, but at least one user is sampled from each user group.

Problem Determination page

Problem determination log level In general, change the problem determination level only when asked to by IBM Software Support.
Under certain conditions, you might want to change the problem determination level.
For example, if problems occur when a run reaches a certain number of users, you might increase the level to Config, which is the most detailed level to use without consulting IBM Software Support.
Only sample information from a subset of users Set a sampling rate.
Fixed number of users Specify the number of users to sample from each user group.
Percentage of users Percentage that you select is sampled from each user group, but at least one user is sampled from each group.

Related tasks

Set the user load

Users	Total number of users to be active in the stage (not the number of users to add or subtract to those currently running).
Run for specified period of time	Length of time (and the time units) for the stage to run. When the number of Users is achieved, the users will run for up to this time. When the time expires, the users continue to run if they are needed for the next stage; otherwise, they are stopped gracefully.

Change Rate	Set a delay between adding or removing each user, rather than adding them or subtracting them all at once. Staggering users avoids overloading the system, which can cause connection timeouts. The User Load Preview shows this time in black.
Settle Time	A system under test might react to a sudden change in user population. With a defined settle time, which starts when the target number of users is reached, the system under test can settle into a steady state so that it can accurately reflect the user population. The User Load Preview shows this time in black.
Time limit for a user to respond to a stop request	Optionally enter a value. When a virtual user is asked to stop, it completes its current action (such as an HTTP request) and then finishes. If a virtual user has not finished within the time limit specified, the user is forced to finish.
User Load Preview	Previews the user population stages over time. The red line segments indicate that the total number of users has been achieved for the state.

Use the recorded think time	Play back a test at the same rate that it was recorded. This option has no effect on the think time.
Specify a fixed think time	Each user's think time is exactly the same value: the value that you specify. Although this does not emulate users accurately, it is useful to play a test back quickly.
Increase/decrease the think time by a percentage	Type a percentage in the Think time scale. Each user's think time is multiplied by that percentage. A value of 100 causes no change in think times. A value of 200 doubles the think times, so the schedule plays back half as fast as it was recorded. A value of 50 reduces the think times by half, so the schedule plays back twice as fast. A value of 0 indicates no delays.
Vary the think time by a random percentage	Each user's think time is randomly generated within the upper and lower bounds of the percentages that you supply. The percentage is based on the recorded think time. For example, if you select a Lower limit of 10 and an Upper limit of 90, the think times will be between 10 percent and 90 percent of the original recorded think time. The random time is uniformly distributed within this range.
Maximum think time	Set a maximum think time is useful with tests that emulate actual think times. By setting a maximum, you do not have to search for and edit each long think time within a test. Numerous factors can generate long think times, for example, you might be interrupted while recording. To restore the original think times, clear this box.

Enable Performance Requirements	Enable the use of performance requirements for this schedule.
Name	Name of this set of performance requirements. Used in the Performance Requirements report. By default, the name is... Performance Schedule - "Schedule_name"
Use Defaults	Click to reset Name to the default value.
Performance Requirement	All performance requirements are displayed in the table. Shaded requirements are not defined for this schedule. To define a requirement, set an Operator and Value.
Operator	Display a list of mathematical operators. Select an operator for this performance requirement.
Value	Set a value for the requirement.
Standard	If a standard requirement is not met, the schedule run will have a verdict of fail, and this verdict will roll up to the entire run, like a verification point failure. Clear to make the requirement supplemental. In general, supplemental requirements are those that are tracked internally. A supplemental requirement cannot cause a run to fail, and its results are restricted to one page of the Performance Requirements report.
Hide Undefined Requirements	See only the requirements that you have defined. This hides the shaded rows.
Clear	Select one or more requirements and click to remove the definition. The requirement is still available and can be redefined.

Enable collection of response time data	Activate response time breakdown for each page element.
Detail level	Select Low or Medium to limit the amount of data collected.
Only sample information from a subset of users	If set the detail level to High or Medium, set a sampling rate to prevent the log from getting too large.
Fixed number of users	Number that you select is sampled from each user group. Unless you have specific reasons to collect data from multiple users, select... Fixed number of users ...and specify one user per user group.
Percentage of users	Percentage that you select is sampled from each user group, but at least one user is sampled from each user group.

Problem determination log level	In general, change the problem determination level only when asked to by IBM Software Support. Under certain conditions, you might want to change the problem determination level. For example, if problems occur when a run reaches a certain number of users, you might increase the level to Config, which is the most detailed level to use without consulting IBM Software Support.
Only sample information from a subset of users	Set a sampling rate.
Fixed number of users	Specify the number of users to sample from each user group.
Percentage of users	Percentage that you select is sampled from each user group, but at least one user is sampled from each group.