Project Settings Details Dialog Box

This dialog box enables you to configure settings for a project.

To access	On the Lab Management sidebar, under Lab Settings, select Project Settings. Right-click a project in the grid, and select Project Settings Details.
Important information	The Controller Options page is available only when logged in to a particular project. You cannot set Controller options in Lab Management.
Relevant tasks	How to Create a Project
See also	Project Settings Overview

Common Elements

Common user interface elements are described below:

UI Elements	Description
	Save. Saves the details.
	First/Previous/Next/Last Entity. Enables you to browse through the list of projects. Available from: Lab Management only
	Spell Check. Checks the spelling for the selected word or text box.
	Thesaurus. Displays a synonym, antonym, or related word for the selected word.
	Spelling Options. Enables you to configure how to check the spelling.
	Field Search. Enables you to search for a specified field name. Supports wildcard search with asterisk "" and question mark "?". For example: `ab` returns `acb` and `adefb`; `a?b` returns `acb`
Project	The name of the project.

PC Target IPs Page

This page enables you to define IP addresses to use as targets for performance testing.

Important Information	Target IP can be defined on Performance Center hosts only, and not on standalone load generators.
Relevant tasks	How to Create a Project
See also	Using Target IP Addresses

User interface elements are described below:

UI Elements	Description
	New. Opens the New Target IP dialog box, enabling you to define an IP to use as a target for performance testing.
	Edit. Opens the Target IP Details dialog box, enabling you to view and edit details of the selected target IP.
	Delete. Enables you to delete the selected target IPs.
	Refresh. Refreshes the grid so that it displays the most up-to-date information.
IP	A target IP address.
Mask	A 32-bit subnet mask for each network.

PC VUDs Transactions Page

This page enables you to follow the PC VUDs transactions in your projects.

User interface elements are described below:

UI Elements (A - Z)	Description
Action	The VUDs action performed. For details about the possible actions, see VUDs Actions.
In Use by Run ID	The ID of the test run that is currently running the VUDs.
Owner Run ID	The ID of the test run that originally issued the VUDs.
Post Date	The date that the transaction occurred.
Responsible user name	The user, or automated system process responsible for the transaction.
Token Unique ID	Identifies all actions that belong to the same transaction. Note: In one regular run that uses VUDs, there are three actions: Issued, Pending, and Expired. Each of these actions has a different transaction ID, but the same Token ID.
Updated in use VUDs	The current number of VUDs that are running as a result of the transaction.
Updated Pending VUDs	The current number of VUDs that are in the Pending state as a result of the transaction.
Updated project limit	The project's VUDs limit as a result of the transaction.
VUDs number	The amount of VUDs involved in the action.
VUDs Transaction ID	The action ID.

VUDs Actions

The following table lists the possible VUDs actions.

UI Elements (A - Z)	Description
Allocated	VUDs added to the project's VUDs limit by the administrator.
Deallocated	VUDs removed from the project's VUDs limit by the administrator.
Expired	VUD's removed from the license after their 24 hour active period has ended. Note: VUDs that are involved in a performance test that exceeds 24 hours continue to run until completion before expiring.
Issued	VUDs added to a performance test. Note: All VUDs involved in a performance test are considered to be issued from the start of the test, irrespective of whether they have started running or not. The amount of issued VUDs decreases the project's VUDs limit accordingly. All unused VUDs are returned to the project's VUDs limit at the conclusion of the test.
Pending	VUDs which have completed a test run but are still available for further use as their 24 hour active period has not yet ended.
Refunded	VUDs which were issued but not used in the test. These VUDs are returned to the project's VUDs limit and may be reissued at a later date.
Reused	Running VUDs that that are taken from VUDs in the Pending state. Note: ALM Performance Center first reuses VUDs in the Pending state before issuing new VUDs. For example, assume you define a performance test that includes 100 VUDs, where the current project limit is 200, and where 25 VUDs are currently in the Pending state. ALM Performance Center first reuses the 25 Pending VUDs and only issues 75 from the license. The new limit will be 125.

Timeslot Settings Page

This page enables you to configure timeslot settings.

User interface elements are described below:

UI Elements	Description
Send Alerts To	The users who should receive a timeslot alert: Timeslot creator. The user who reserved the timeslot. Timeslot modifier. The user who last modified the timeslot. Project administrators. Administrators of the project in which the timeslot was reserved.
Rules for Alerts	The conditions under which timeslot alerts are sent (both conditions must hold): Send alerts for timeslots scheduled to start in the next <XX> hours. Sends an alert when a timeslot is XX hours within its due time to start. Default value: 72 hours Minimum value: 12 hours Send alert if timeslot is in failure state for at least <XX> minutes. Sends an alert when the timeslot has been invalid for XX minutes. Default value: 30 minutes Maximum value: 360 minutes (6 hours)
Autostart Retries	If a performance test linked to a timeslot is scheduled to autostart but does not start running, the system continues to try to autostart the test until it starts running successfully. The Autostart Retries option enables you to specify when the system should stop trying to autostart the test. In any event, retries are stopped if there are 30 minutes or less left of the timeslot. Default value: 50%, that is the system stops retries when half the timeslot has elapsed. Maximum value: 99%; Minimum value: 1% Note: The system tries to restart a performance test up to three times.

UI Elements

Description

Send Alerts To

The users who should receive a timeslot alert:

Timeslot creator. The user who reserved the timeslot.
Timeslot modifier. The user who last modified the timeslot.
Project administrators. Administrators of the project in which the timeslot was reserved.

Rules for Alerts

The conditions under which timeslot alerts are sent (both conditions must hold):

Send alerts for timeslots scheduled to start in the next <XX> hours. Sends an alert when a timeslot is XX hours within its due time to start.

Default value: 72 hours

Minimum value: 12 hours
Send alert if timeslot is in failure state for at least <XX> minutes. Sends an alert when the timeslot has been invalid for XX minutes.

Default value: 30 minutes

Maximum value: 360 minutes (6 hours)

Autostart Retries

If a performance test linked to a timeslot is scheduled to autostart but does not start running, the system continues to try to autostart the test until it starts running successfully.

The Autostart Retries option enables you to specify when the system should stop trying to autostart the test. In any event, retries are stopped if there are 30 minutes or less left of the timeslot.

Default value: 50%, that is the system stops retries when half the timeslot has elapsed.

Maximum value: 99%; Minimum value: 1%

Note: The system tries to restart a performance test up to three times.