Login VSI - How to have fun with Phases

Please note. This is an unsupported use of the phasing feature of Login VSI and stopped functioning in 4.1.25. Please use an older version if you wish to continue to use phasing in the way described below.

Fun with Phases

During performance testing, do you want all users in a given test to logon and then have the test execute? This is done by manipulating Phases.

Manipulating Phases not only allows what is described here but also opens the door to other delayed or modified test scenarios.

Overview

The concept is as follows:

1. VSI.exe is delayed until every user is logged on.
2. Once every user is logged on a delay is started.
3. After the (configurable) delay has expired every session starts running the workload after another delay. The idea is that this delay allows sessions to still become active in a gradual way.
4. Sessions run the workload as they would before, except the load on the environment starts after a configured amount of time, once every user has already logged on.

Details

You start off with four files downloaded from http://upload.loginvsi.com/Support/Jul15/Delayed.zip

• Delayed.ps1. This file should go into \\server\vsishare\_VSI_Binaries\target
• logon.cmd. This file should go into \\server\vsishare\_VSI_Binaries\target
• delete.cmd. This file should go into \\server\vsishare\
• timing.csv. This file should go into \\server\vsishare\

Delayed.ps1

Delayed.ps1 does the brunt of the work. It is a script that will delay the start of VSI until every user has been logged on. The script simply does this by waiting for a file to exist in the VSIshare. After that point the script will read the CSV file described below to determine the delay. The idea behind the delay is that user 1 waits 30 seconds, users 2 waits 60 seconds, user 3 waits 90 seconds, etc. This ensures that users are still generating load in a gradual way. The script will look up the value for this delay by looking up the username in the CSV file.

Timing.csv

The command line that VSI uses in this scenario is held in the CSV file. That way we can use phasing within the VSI management console to control when a test starts and when the load on the environment starts. It contains 3 "sections":

1. The normal CSV like data. It contains a line for every user with a command line.
2. The start load section. As explained above, the PS script waits for the existence of a file. This section will create that file. It simply contains the command line needed to create this file.
3. The removal of the Start Load file from step 2.

The CSV file also contains columns for username and delay. The username is required for the Delayed.ps1 script, it will use the username as a "key" to lookup the delay it needs to use.

The CSV file will look something like:

Where the command line for the first sections will be the command line you use in your environment. The last 3 lines control the start of the load.

logon.cmd

This is the default VSI logon script with 1 exception. It will trigger the PowerShell script (Delayed.ps1) first and wait for it to complete. Causing VSI to pause execution until the script finishes.

delete.cmd

This script simply deletes the StartTest file. Making sure that you can actually run a test the next time.

Management Console Configurations

In the Management Console under “Scenario” you need to configure at least 4 phases:

1. Normal VSI phase – This is the actual number of sessions you want to run in the test. 
2. A “Delay” phase -  This delay phase allows the sessions that just logged on to "calm down".  It will trigger the “PausedDummy” line in the CSV.
3. A “StartLoad” phase - This is simply a dummy phase. It will trigger the dummy,dummy,fsutil file createnew c:\vsishare4\StartTest.txt 0 line in the CSV file.
4. A “Cleanup” phase - This is another dummy phase. It will trigger the dummy,dummy,\\server\vsishare\delete.cmd line in the CSV file.

In the Management Console under “Connection” you will configure it like this:

Know issues and/or disclaimers

Please note that a few scenarios need to be taken into consideration:

1. Since this concept delays the initial logon script. It is advised to not have the Run logon script synchronously setting enabled. As the whole idea of this concept is to delay the start of the test until all users are done logging in. Enabling the setting linked will cause Windows to delay the logon process until delayed.ps1 has finished. 
2. Please note that the analyzer starting from version 4.1.10 and beyond will report sessions that didn't log on successfully. As we are launching 3 dummy sessions your reports will show 3 sessions that failed to launch.