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 Maintenance > 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. For details, see Filter.

Alternatively, click the filter box under the column you want to filter, and select a filter (or enter text to filter).

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. Click the project name link to display the project's details in the Main Details view.
Domain

The domain in which the project was created.
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.
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.

Project Unique ID

The project's ID.
VUDs Consumed

The number of VUDs consumed by the project.
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.
Host Limit

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

The AUT host pool of the project.
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.
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. Enables users to choose whether to upload runtime setting files only or all files. If you select Runtime Mode, only the .usz file is uploaded to Performance Center. If you select All Files Mode, all available files including thumbnail images are uploaded (the script size is much larger).
Recurrent Timeslot Indicates whether the recurrent timeslot reservations are enabled or disabled (default) for the project. For details, see Enable recurring timeslots.
Diagnostics Server

The Diagnostics Server defined for the project.

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.

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.