Start your first test

From Login VSI Documentation
Revision as of 22:15, 24 October 2013 by Dennis (talk | contribs) (Created page with "=Start your first test= In this chapter the steps required to start your first test are described. ==Requirements== * VSIshare * Login VSI Management Console * At least 1 la...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Start your first test

In this chapter the steps required to start your first test are described.


  • VSIshare
  • Login VSI Management Console
  • At least 1 launcher




First we are going to start the Session monitor. The Session Monitor needs to run on the server that is hosting the VSIshare.

Browse to the local VSIshare to the following location: {VSIshare}\_VSI_Binaries\Launcher\

Start the SessionMonitor.exe.

Provide the location of the local file share.

Click on start to start the session monitor

Start the Login VSI Management Console

Click on 6. Start Test

This page will contain an overview of the current configured settings.

Click in the top right corner start test.

Click next.

To automatically logoff all sessions mark the Logoff sessions when all session have been launched. By default 120 seconds is configured.

Click next.

Provide a name for the first test.

Click next.

Mark the checkbox Use launcher workflow.

Enter the Launcher username: Launcher-v4

Enter the Launcher password: Password!

Click next.

This feature is only available in Login VSI PRO, express users can skip this step.

Click next.

This feature is only available in Login VSI PRO, express users can skip this step.

Click on next.

The launcher workflow will launch a RDP connection to the launcher.

The automatic agent start feature (launcher workflow) is only available in Login VSI PRO, express users have to make sure that \\server\VSIshare\_VSI_binaries\Launcher\Agent.exe is running at the Launcher machine.

When the launcher agent.exe is running he will inform the Management Console that he is ready.

The launcher will give the status ready.

Click on next.

Make sure the launcher is added by HOSTNAME only, not IP of FQDN otherwise the status will stay pending at “waiting”

Click on finish

The launcher will start the connections to the target.

The dashboard will open automatically and will provide you the information of current test.

For a detailed overview of the dashboard please see chapter ….

Finishing your first test




The Dashboard will indicate when a test is finished. On the bottom the message “The test is finished, please click “reload” to reload this page.”

Analyzing the results

The Login VSI Analyzer will process the data collected during the VSI workload. The analyzer will calculate if the target environment has reached it saturation point and if so, at how many concurrent session. This point is called VSImax.



Start the Login VSI Analyzer by clicking the Analyzer button in the bottom left corner of the Login VSI Management Console.

The location of the cache and the location of the VSIshare will need to be specified if the Analyzer runs for the first time.

Specify the path to the VSIshare. Change the location of the cache if desired. Click Save to continue.

Select the test that you want to analyze and click Open to start the analysis.

Analyzer tabs

VSImax v4



The VSImax v4 tab is the main tab of the Login VSI analyzer. This tab shows the most important information.

This section shows the following.

VSImax v4:

VSImax v4 shows the amount of sessions can be active on a system before the system is saturated. The blue X shows the point where VSImax was reached. This number gives you an indication of the scalability of the environment (higher is better).


VSIbase is the performance of the system while there is no load on the environment. This number is used to determine what the performance threshold will be. VSIbase gives an indication of the base performance of the environment (lower is better). VSIbase is also indicated within the graph.

VSImax v4 threshold:

VSImax v4 threshold indicates at which point the environments saturation point is reached. It is based on VSIbase. VSImax v4 threshold is also indicated within the graph.

Stuck sessions:

How many sessions got stuck during the test. This number should be 0. Stuck sessions indicate a problem during the test. As stuck session do not generate load the VSImax score will be reduced by the number of stuck sessions.

''''Minimum Response:

Minimum response indicates the minimum response time for all the measurements taken when the indicated number of sessions on the X axis were active.

Average Response:

Average response indicates the average response time for all the measurements taken taken when the indicated number of sessions on the X axis were active.

Maximum Response:

Maximum response indicates the maximum response time for all the measurements taken when the indicated number of sessions on the X axis were active.

VSI Index Average:

VSI Index Average indicates the average value as calculated by VSI. The VSI Index Average differs from Average Response on the fact that Average Response is the pure average. VSI Index Average applies certain statistical rules to the average to avoid spikes from influencing the average too much.

VSImax v4 detailed



The VSImax v4 detailed tab shows the individual measurements taken during a test in a combined graph. This graph shows the minimum, average and maximum response times for each individual measurement. There is also a Total metric that combines all of the metric into a single number. The minimum, average and maximum for this combined value is shown as well.

The metrics are as follows.


The sum of all the metrics.


File Copy Doc Local. Copy a doc (Microsoft Word) file locally.


File Copy Doc Share. Copy a doc (Microsoft Word) file from the VSI content location to the local file system.


File Copy Text Local. Copy a txt (plain text) file locally.


File Copy Text Share. Copy a txt (plan text) file locally.


Notepad File Print. Open the print dialog in notepad.


Notepad Start/LoaD file. Start notepad by file type association, loading a text file.


Windows File Open. Open the file > open dialog in notepad.


Word File Start/LoaD. Open Microsoft Word by file type association, loading a doc file.


Zip High Compression. Zip a PST (Outlook Personal Folder) file, which is approximately 5 megabytes in size, using high compression.


Zip No Compression. Zip a PST (Outlook Personal Folder) file, which is approximately 5 megabytes in size, using no compression.

VSImax v4 Scatter



The VSImax Scatter tab allows you to see the measurements based on time. Every tab before this tab shows the measurements consolidated by active session count. This tab allows you to see the data based on the time it was collected.

This is particularly useful to get an insight in trends after the sessions have finished logging on. The other tabs will consolidate all of the data collected after the last session has become active into a single data point. Namely the last active session count.




These tabs show information for the individual measurements taken during the test. These specific measurements are zoomed in to because they are used to calculate VSIbase and VSImax v4 threshold.

The tab is similar to the VSImax v4 detailed tab except that it, by default, will only show the measurement for the tab. The graphs scale has also been scaled for the individual measurement.

The tab will also display the baseline value for this measurement. This is the time it takes to complete this measurement during baseline measurements. These measurements are taken while the system is under no or very little load. It is used to see how the measurement trends from a system that isn’t under load.

These tabs also allow you to add any of the other metrics. The baseline for the tabs specific metric will not disappear though.




The LogonTimer tab gives you an indication of the time it takes for a session to logon. The graph shows the trend of logon times during the test. The logon time is specified in seconds.

Please note that this is an indication of the logon time. VSI measures the time from the logon scripts running, shortly after group policy has been processed but before the shell has loaded (Windows Explorer), and the windows shell being loaded.

VSImax v4 Data & Raw Data

These tabs contain the raw and processed data used to create the graphs in the analyzer. You can use this data to run your own analysis on.



The philosophy behind Login VSI is different to conventional benchmarks. In general, most system benchmarks are steady state benchmarks. These benchmarks execute one or multiple processes, and the measured execution time is the outcome of the test. Simply put: the faster the execution time or the bigger the throughput, the faster the system is according to the benchmark.

Login VSI is different in approach. Login VSI is not primarily designed to be a steady state benchmark (however, if needed, Login VSI can act like one). Login VSI was designed to perform benchmarks for SBC or VDI workloads through system saturation. Login VSI loads the system with simulated user workloads using well known desktop applications like Microsoft Office, Internet Explorer and Adobe PDF reader. By gradually increasing the amount of simulated users, the system will eventually be saturated. Once the system is saturated, the response time of the applications will increase significantly. This latency in application response times a clear indication whether the system is (close to being) overloaded. As a result, by nearly overloading a system it is possible to find out what its true maximum user capacity is.

After a test is performed, the response times can be analyzed to calculate the maximum active session/desktop capacity. Within Login VSI this is calculated as VSImax. When the system is coming closer to its saturation point, response times will rise. When reviewing the average response time it will be clear the response times escalate at saturation point. With previous versions of Login VSI (LoginVSI 3.x and older), if the system was not saturated during the test, it will not be able to calculate VSImax. This has changed with LoginVSI 4.0.

This VSImax is the “Virtual Session Index (VSI)”. With Virtual Desktop Infrastructure (VDI) and Terminal Services (RDS) workloads this is valid and useful information. This index simplifies comparisons and makes it possible to understand the true impact of configuration changes on hypervisor host or guest level.

Server side response time measurements

It is important to understand why specific Login VSI design choices have been made. An important design choice is to execute the workload directly on the target system within the session instead of using remote sessions. The scripts simulating the workloads are performed by an engine that executes workload scripts on every target system, and are initiated at logon within the simulated user’s desktop session context.

An alternative to the Login VSI method would be to generate user actions client side through the remoting protocol. These methods are always specific to a product and vendor dependent. More importantly, some protocols simply do not have a method to script user actions client side.

For Login VSI the choice has been made to execute the scripts completely server side. This is the only practical and platform independent solution, for a benchmark like Login VSI. The relative overhead and footprint of a benchmark engine scripted in AutoIT is small enough (1-5% range) for Login VSI’s purposes.

Calculating VSImax v4

The simulated desktop workload is scripted in a 48 minute loop when a simulated Login VSI user is logged on, performing generic Office worker activities. After the loop is finished it will restart automatically. Within each loop the response times of twelve specific operations are measured in a regular interval: twelve times in within each loop. The response times of these six operations are used to determine VSImax.

The six operations from which the response times are measured are:

Starting “VSI Notepad”

This operation is handled by the OS (loading and initiating VSINotepad.exe) and by the VSINotepad.exe itself through execution. This operation seems almost instant from an end-user’s point of view.

Starting the “File Open” dialogue

This operation is handled for a small part by Word and a large part by the operating system. The file open dialogue uses generic subsystems and interface components of the OS. The OS provides the contents of this dialogue.

Starting the “Print” dialogue

This operation is handled for a large part by the OS subsystems, as the print dialogue is provided by the OS. This dialogue loads the print-subsystem and the drivers of the selected printer. As a result, this dialogue is also dependent on disk performance.

Compress the document into a zip file with 7-zip command line (2x)

This operation is handled by the command line version of 7-zip. The compression will very briefly spike CPU and disk IO. This action is performed twice: once with no compression (IO intensive) and with high compression (CPU intensive)

''''Starting Microsoft Word with a document

This operation will measure the responsiveness of the Operating System and the file system. Microsoft Word is started and loaded into memory, also the new document is automatically loaded into Microsoft Word. When the disk IO is extensive or even saturated, this will impact the file open dialogue considerably.

These measured operations within Login VSI do hit considerably different subsystems such as CPU (user and kernel), Memory, Disk, the OS in general, the application itself, print, GDI, etc. These operations are specifically short by nature. When such operations become consistently long: the system is saturated because of excessive queuing on any kind of resource. As a result, the average response times will then escalate. This effect is clearly visible to end-users. If such operations consistently consume multiple seconds the user will regard the system as slow and unresponsive.

Figure 1 Sample of a VSI max responsetime graph, representing a normal test

Figure 2 Sample of a VSI test responsetime graph where there was a clear performance issue

Once the test is finished, VSImax v4 can be calculated. Previous VSImax models (Classic and Dynamic) could not be calculated when the system was not saturated. In VSImax v4 this is not a requirement anymore. When the system is not saturated, and it could complete the full test without exceeding the average response time latency threshold, VSImax is now considered the maximum of active sessions that were launched.

The response times are very different per measurement type, for instance Zip with compression can be around 2800 ms, while the Zip action without compression can only take 75ms. These response time of these actions are weighted before they are added to the total. This ensures that each activity has an equal impact on the total response time.

In comparison to previous VSImax models, this weighting much better represent system performance. All action have very similar weight in the VSImax total, both in VSImax classic and dynamic the opening of word had far greater impact on the total than other activities. The following weighting of the response times are applied:

The following actions are part of the VSImax v4 calculation and are weighted as follows:

• Start VSINotepad with large text file: 0.5

• Start File Open Dialogue: 1.25

• Start Print dialogue: 4

• Zip PST file without compression: 6

• Zip PST file with high compression: 0,175

• Start Word with new document from document pool: 0,15

This weighting is applied on the baseline and normal Login VSI response times.

The average VSImax baseline response time (also called VSIbase) in Login VSI 4.0 is calculated from the results recorded in the baseline phase. In total 30 VSI response time samples are takes by 5 baseline sessions. To ensure the VSIbase represents the optimal performance of the system, the highest 15 results are removed from the average calculation. To ensure no fluke low measurements are affecting the results unrealistically, the bottom 2 results are removed from the average VSIbase calculation. Over the remaining 13 VSI response time measurements the average VSImax baseline response time VSIbase is calculated.

The VSImax average response time in Login VSI 4.0 is calculated on the amount of active users that are logged on the system.

Always a 5 Login VSI response time samples are averaged + 40% of the amount of “active” sessions. For example, if the active sessions is 60, then latest 5 + 24 (=40% of 60) = 31 response time measurement are used for the average calculation.

To remove noise (accidental spikes) from the calculation, the top 5% and bottom 5% of the VSI response time samples are removed from the average calculation, with a minimum of 1 top and 1 bottom sample. As a result, with 60 active users, the last 31 VSI response time sample are taken. From those 31 samples the top 2 samples are removed and lowest 2 results are removed (5% of 31 = 1.55, rounded to 2). At 60 users the average is then calculated over the 27 remaining results.

VSImax v4 is reached when the VSIbase + a 2600 ms latency threshold is not reached by the average VSI response time result. Depending on the tested system, VSImax response time can grow 2 - 3x the baseline average. In end-user computing, a 3x increase in response time in comparison to the baseline is typically regarded as the maximum performance degradation to be considered acceptable.

Note: In VSImax Dynamic the latency threshold was dependent on the baseline measurement at the beginning of the test. 25% of the baseline measurement was added to a latency threshold. While this was not a problem with most tests, in some cases, especially when the systems performance was very close between two different configurations, the slower system might get a higher VSImax score simply because the higher baseline results gave the slower system a higher latency threshold.

In VSImax v4 this latency threshold is fixed to 2600ms, this allows better and fairer comparisons between two different systems, especially when they have different baseline results. Ultimately, in VSImax v4, the performance of the system is not decided by the total average response time, but by the latency is has under load. For all systems, this is now 2600ms (weighted).

The threshold for the total response time is: average weighted baseline phase response time + 2600ms.

When the system has a weighted baseline response time average of 1500ms, the maximum average response time may not be greater than 4100ms (1500+2600). If the average baseline is 3000 the maximum average response time may not be greater than 5600ms (3000+2600).

VSImax v4 is determined before the system has exceeded it threshold. For example, when the VSI max average on system has exceeded the VSI threshold at 80 users, the VSImax will be 79.

When the threshold is not exceeded by the average VSI response time during the test, VSImax is now considered the maximum amount of users that was launched. This approach is fundamentally different in comparison to previous VSImax methods, as is it was always required to saturate the system beyond VSImax threshold.

Lastly, VSImax v4 is now always reported with the average baseline VSI response time result. For example: “The VSImax v4 was 125 with a baseline of 1526ms”. This helps considerably in the comparison of systems and gives a more complete understanding of the system. The baseline performance helps to understand the best performance the system can give to an individual user. VSImax indicates what the total user capacity is for the system. These two are not automatically connected and related:

When a server with a very fast dual core CPU, running at 3.6 GHZ, is compared to a 10 core CPU, running at 2,26 GHZ, the dual core machine will give and individual user better performance than the 10 core machine. This is indicated by the baseline VSI response time. The lower this score is, the better performance an individual user can expect.

However, the server with the slower 10 core CPU will easily have a larger capacity than the faster dual core system. This is indicated by VSImax v4, and the higher VSImax is, the larger overall user capacity can be expected.

With Login VSI 3.6 it is was possible to choose between ‘VSImax Classic’ and 'VSImax Dynamic’. With Login VSI 4.0 a new VSImax method is introduced: VSImax v4. This methodology gives much better insight in system performance and scales to extremely large systems. ‘VSImax Classic’ and 'VSImax Dynamic’ are not suitable for large systems.

VSImax Classic

VSImax Classic is based on the previous versions of VSI, and is achieved when the average VSI response time is higher than a fixed threshold of 4000ms. This method proves to be reliable when no anti-virus or application virtualization is used.

In practice however, tests have shown a substantial increase of application response time when antivirus and/or application virtualization is used. The baseline response time is typically around 1400 - 1800 ms without application virtualization or antivirus. However, when anti-virus or application virtualization is used, the baseline response time varies between 2500 – 3500 ms.

When the baseline response time is already so high the VSImax Classic threshold of 4000ms is too easily reached. ‘VSImax Classic’ will report a maximum long before system resources like CPU, RAM or disk are actually saturated.

It was therefore decided to further optimize VSImax calculation.

VSImax Dynamic

Similar to ‘VSImax Classic’, VSImax Dynamic is calculated when the response times are consistently above a certain threshold. However, this threshold is now dynamically calculated on the baseline response time of the test. VSImax Dynamic was introduced in VSI 3.0.

For this the average VSImax response times need to consistently higher than a dynamically calculated threshold. To determine this dynamic threshold, first the average baseline response time is calculated. This is done by averaging the baseline response time of the first 15 VSI users on the system.

The formula for the dynamic threshold is: Avg. Baseline Response Time x 125% + 3000. As a result, when the baseline response time is 1800, the VSImax threshold will now be 1800 x 125% + 3000 = 5250ms.

Especially when application virtualization is used, the baseline response time can wildly vary per vendor and streaming strategy.