This topic describes host allocation and provides an example of how hosts are allocated and reshuffled among timeslots.
Host allocation overview
When reserving a timeslot, the system calculates the availability of all the requested hosts and, in the case of a Performance Test timeslot, Vusers. A timeslot can be reserved successfully only if all of the requested hosts can be allocated, and in the case of a Performance Test timeslot, if all the requested Vusers are available.
Performance Testing. You must request at least one Controller and one Load Generator. If you have linked a test to the timeslot, the hosts and Vusers defined in the test are automatically requested for the timeslot.
Hosts are allocated as follows:
-
A specific host defined in the Testing Host grid can be allocated for testing as long as it is available and operational. A specific host can be allocated for maintenance even if it is non-operational.
Note: You can make specific hosts available only to specific users. For details, see Manage hosts.
-
An Automatch host is matched up with a specific host that has the requested properties. A host is allocated after the following criteria have been checked:
-
LoadRunner Enterprise creates a list of all the hosts in the host pool of the project that are operational and available, and that match the requested properties of the automatch host.
-
From this list of candidate hosts, the system allocates the host that best fits the requested properties, taking into account the host priority, the number of pools the host belongs to, the purposes assigned to the host, and the host's attributes. The hosts are then allocated in such a way that other hosts with similar but also additional properties may still be available for allocation to other test executions.
-
It is important to note that many conditions and changes in the system can occur that can affect host allocation. At such times, the system attempts to optimize the overall resource usage by reshuffling the hosts that are available among the timeslots.
It is not always possible to shuffle the hosts appropriately. When this happens, a timeslot might become partially allocated, and thus invalid. As soon as the requested host becomes available again or another host can be allocated instead, the timeslot becomes valid again.
Example:
- If an allocated host becomes non-operational, then the system will try to find another host to replace the non-operational host.
-
In a version-enabled project, if a test is linked to an automatic timeslot and is checked out, modified, and checked in again before the timeslot starts, the timeslot recalculates the availability of the updated resources.
Example of allocating and reshuffling hosts
Overview
There are many factors that can affect the allocation of hosts among timeslots.
Consider the following scenarios which illustrate how hosts are allocated among performance timeslots and how changes in the available testing hosts can affect the host allocation.
You will see that LoadRunner Enterprise attempts to optimize the overall resource usage by reshuffling the hosts that are available among the timeslots.
Available host pool
Assume the following hosts belong to the host pool of the project:
|
Host |
Properties |
|---|---|
|
Host1 |
Controller |
|
Host2 |
Controller + Load Generator |
|
Host3 |
Load Generator with the following property:
|
|
Host4 |
Load Generator with the following properties:
|
07:00 am: John reserves a timeslot
John reserves the following timeslot at 07:00 am:
|
Timeslot |
Reserved at |
Reserved for |
Requested Resources, Properties |
|---|---|---|---|
|
TS1 |
07:00 |
08:00am - 10:00am |
1 Controller, Any 1 Load Generator, Any |
John submits the request. The system allocates Host1 as the Controller, leaving Host2 available to serve as either load generator or Controller in other timeslots. Additionally, the system allocates Host4 as the load generator, since it has higher priority than both Host2 and Host3. The following hosts are allocated successfully:
|
Requested Hosts |
Allocated Hosts |
|---|---|
|
1 Controller, Any |
Host1 |
|
1 Load Generator, Any |
Host4 |
07:30 am: Sue submits a timeslot reservation
Sue submits the following timeslot reservation at 07:30 am:
|
Timeslot |
Reserved at |
Reserved for |
Requested Resources, Properties |
|---|---|---|---|
|
TS2 |
07:30 |
09:00am - 11:00am Autostart |
1 Controller, Any 1 Load Generator, Citrix |
Because Host4 is the only Citrix load generator, the system checks if it can allocate a different load generator to John's timeslot so that Host4 can be allocated to Sue's timeslot instead.
Hosts are reshuffled to accommodate Sue's request
The necessary hosts are available, so the following reshuffle occurs:
-
Host3 is allocated to John; Host4 is allocated to Sue
-
John's Controller, Host1 remains allocated to John; Host2, also a Controller, (not yet allocated), is allocated to Sue
Sue successfully submits the request. The new host allocation looks as follows:
|
Timeslot |
Requested Hosts |
Allocated Hosts |
|---|---|---|
|
TS1 |
1 Controller, Any 1 Load Generator, Any |
Host1 Host3 (replaced Host4) |
|
TS2 |
1 Controller, Any 1 Load Generator, Citrix |
Host2 Host4 |
Note: Host allocation works on a "first-come, first-served" basis. Since John reserved Host4 first, if there had been no other host to allocate to his timeslot, Host4 would have remained allocated to John, and Sue would not have been able to reserve her timeslot successfully.
07:45 am: Peter reserves a timeslot
Peter reserves the following timeslot at 07:45 am:
|
Timeslot |
Reserved at |
Reserved for |
Requested Resources, Properties |
|---|---|---|---|
|
TS3 |
07:45 |
10:00am - 12:00pm |
1 Controller, Host2 1 Load Generator, Any |
Peter is specifically requesting Host2 for his Controller, and any load generator. The system checks if the requested hosts can be allocated, taking into consideration requests and timing of the other timeslots:
-
To allocate Host2 to Peter's timeslot, it must be available by 10:00.
-
Sue is willing to have any Controller.
-
John's timeslot will end at 10:00 and free resources.
Hosts are reshuffled to accommodate Peter's request
The following reshuffle occurs so that all the timeslots can be accommodated:
-
Sue's timeslot gives up Host2, and is allocated Host1 instead; Host4 (Citrix) remains allocated to Sue's timeslot
-
Host2 is allocated to John's timeslot; Host3 remains allocated to John's timeslot
-
Host2 and Host3 can then be allocated to Peter's timeslot because John's timeslot will be finished by 10:00 when Peter's starts.
Peter successfully submits his request. The new host allocation looks as follows:
|
Timeslot |
Requested Hosts |
Allocated Hosts |
|---|---|---|
|
TS1 |
1 Controller, Any 1 Load Generator, Any |
Host2 Host3 |
|
TS2 |
1 Controller, Any 1 Load Generator, Citrix |
Host1 Host4 |
|
TS3 |
1 Controller, Host2 1 Load Generator, Any |
Host2 Host3 |
Note: If John and Peter's timeslots had overlapped, Host2 would not have been available for part of Peter's timeslot. In this case, the reshuffle would not have been possible and Peter would not have been able to reserve his timeslot successfully.
Hosts are reshuffled as they become available
Now let's say at 07:55 Host2 becomes non-operational. As a result, TS1 takes back Host1, and starts at 08:00. It follows from the information above, that TS2 and TS3 both become invalid as their resources have become partially allocated.
Then, at 09:05, Host2 becomes operational again. It is allocated to TS2, and TS2 starts, though five minutes late, but still during the specified retries period. (For details about configuring retries, see Manage projects.)
At 11:00, TS3 remains invalid (partially allocated) and is unable to start because Host2 is still being used by TS2.
See also:
