Define Project Settings

You can view and modify project settings, define IP addresses to use as targets for performance testing, and follow VUD Vuser allocation and usage in the Projects page.

View or modify the project settings

To view project settings in Performance Center Administration, select Management > Projects.

To edit project settings, under the Project Name column, click a project. By default, the Main Details view is displayed.

Note:  

  • You create projects in Site Administration and configure timeslot alerts in ALM Lab Management.

  • You can also manage project settings in ALM Lab Management.

    For details, see the ALM Lab Management Guide.

Projects Page - Main Details View

This page enables you to view and manage all of the projects and their settings.

Field

Description

Filter. Enables you to filter projects to display only those projects that meet the criteria that you define.

The filter selection is displayed above the projects menu:

Refresh. Refreshes the grid so that it displays the most up-to-date information.

Select Columns. Enables you to determine which fields to display in the grid.
Project Name

The name of the project.

ID The project's ID.
Last Run

The time and date of the last test run in the project.

Pool Name

The project's host pool.

AUT Pool

The AUT host pool of the project.

Vuser Limit

The maximum number of Vusers available to the project.

Concurrent Run Limit

The maximum number of concurrent test runs allowed within a project.

Host Limit

The total number of hosts (Controller + load generators) reserved for a timeslot may not exceed this limit.

VUDs Limit

The maximum number of Virtual User Days (VUDs) a project can run at once. The total number used by all of the project's concurrent performance tests must not exceed this limit.

VUDs Consumed

The number of VUDs consumed by the project.

Domain Name

The domain in which the project was created.

Diagnostics Server

The Diagnostics Server defined for the project.

Project Full Name

The domain and project name.

VuGen Working Mode

The mode to use to upload scripts from VuGen:

  • Runtime Files. Uploads only the necessary files to replay the script correctly.

  • User Defined. Uploads any available files including thumbnail images.

Build Verification Suite Auto-Extend Duration

The number of minutes by which a build verification suite timeslot is automatically extended if the initial timeslot is not long enough. Requires that Automatically Extend Timeslot is enabled for the timeslot and requires that the appropriate testing resources are available to extend the timeslot.

Max Times to Automatically Extend Timeslot

The maximum number of times that a timeslot can be automatically extended if the initial timeslot is not long enough for the test set to complete.

Project Unique ID

The project's ID.

Post-Run Action

Select the action that is triggered automatically when the test run ends. This does not replace the user privileges, and is not enforced on collate or analyze actions that can be performed by the user from the Test Runs page at a later time.

  • Unrestricted (user-defined). Enables the user to select the post-run action when they start or stop a test, or when they select a timeslot.

  • Do not collate results. Frees the machines immediately after the performance test ends. When the run has finished, the run results are left on the load generators.

  • Collate results. When the run has finished, the run results are collected from all the load generators. This is recommended because collation of results takes only a few minutes, and can prevent loss of or inaccessibility to results in case any of your load generators becomes unavailable.

  • Collate and analyze results. When the run has finished, the run results are collected and analyzed. Data analysis requires some time, depending on the size of the results file.

Note:

  • If you set the post-run action to Unrestricted (user-defined) and subsequently change the setting after a user has reserved a timeslot, Performance Center will not enforce or modify the settings in reserved timeslots where it conflicts with the user's post-run action setting.

  • When you set a post-run action other than Unrestricted (user-defined), the selected action will be set as the only option for tests across the project, and users will not be able to change this setting.

  • If you set a post-run action for which a user lacks permissions in ALM (for example, you set the post-run action to Collate and analyze results, and the user does not have Analyze permissions), the user is unable to run or reserve a timeslot for the test. In such circumstances, update the user’s permissions in ALM, or contact the ALM project administrator. For details on setting user permissions in ALM, refer to the ALM Administrator Guide in the ALM Help Center.

  • Post-run actions are not applicable for test runs driven by the REST API or Jenkins plugin. They are enforced for tests driven from the user interface only.

Projects Page - PC Target IPs View

The PC Target IPs view enables you to define IP addresses to use as targets for performance testing.

Note: Target IP can be defined on Performance Center hosts only, and not on standalone load generators.

Field

Description

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. For more details, see Use target IP addresses.
Mask A 32-bit subnet mask for each network.
Adds the IP address and 32-bit subnet mask to the PC Target IPs list.

Projects Page - PC VUDs Transactions View

The PC VUDs Transactions view enables you to follow the PC VUDs transactions in your projects.

Field

Description

VUDs Transaction ID The action ID.
Post Date

The date that the transaction occurred.

Action The VUDs action performed. For details about the possible actions, see VUDs actions.
VUDs Number The project's VUDs limit.
In Use by Run ID The ID of the test run that is currently running the VUDs.
Updated Pending VUDs The current number of VUDs that are in the Pending state as a result of the transaction.
Responsible The user, or automated system process responsible for the transaction.
Updated in use VUDs The current number of VUDs that are running as a result of the transaction.
Owner Run ID The ID of the test run that originally issued the VUDs.
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.

Project Unique ID The project ID.

Back to top

Use target IP addresses

Target IP addresses are assigned so that the addresses of all hosts on a given network share a common prefix. The common prefix defines the network portion of the IP address, and the remainder defines the host portion (also referred to as the local portion).

The term network in this context refers to a logical network which might span one or more physical networks. The network portion of an IP address identifies a site and the local portion identifies a single host at that site.

Using Subnet Masks

A site using subnet addressing must specify a 32-bit subnet mask for each network. Each bit in the subnet mask is set to 1 if the network treats the corresponding bit in the IP address as part of the network address or 0 if it treats the corresponding bit in the IP address as part of the host ID.

Consider, for example, the subnet mask

11111111 11111111 0000000 0000000

(or in decimal form, 255.255.0.0). This subnet mask specifies that the first two octets identify the network and the last two octets identify the host on that network.

The subnet mask 255.255.255.255 (or in binary form, 11111111 11111111 11111111 11111111), which you add when defining individual IP addresses, specifies that all four octets in the IP address identify the network and host as if there were no subnet mask. In practice, this means that null uses the exact IP address to target performance tests.

VUDs actions

The following table lists the possible VUDs (Virtual User Day) actions. For details of VUDs, see Performance Center licenses overview.

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

VUDs 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 are taken from VUDs in the Pending state.

Note: 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. Performance Center first reuses the 25 Pending VUDs and only issues 75 from the license. The new limit will be 125.