Setting up Agent and Controller on the same machine with VSTT 2008

If you have only one multi-proc machine to generate user load on your application, you can set up the Agent and the Controller to be the same machine. Just one little tip; when assigning a test to a an agent, don’t select the “local” radio button. Picking this option will select VSTestHost.exe to run the test which in turn will use only one processor (ref: Generating heavy loads in VSTT 2008: What has changed?)

So, on the Agent Configuration screen, choose Remote and then assign “localhost” as the agent. This configuration will use QTAgent.exe and hence use multiple procs to simulate higher loads.

Generating heavy loads in VSTT 2008: What has changed?

In my previous post, Generating heavy loads using Visual Studio Team System for Testers 2005, I explained how the the GC configuration can be changed for generating heavy loads on Multi-proc machines.

For Visual Studio Team Suit 2008 for Testers , there is a change. VSTestHost.exe is now hardcoded to use only one CPU. Which means, even if you change the GC settings in the config file, it will be overridden with hardcoded Workstation GC settings.

To generate heavy loads using VSTT 2008, you have to use the Agent/Controller setup. Once the Agent/Controler has been configured, change the Server GC settings in QTAgent.exe.config on the Agent machine and you will be good to go.

Generating heavy loads using Visual Studio Team System for Testers 2005

To generate heavy loads on Multi-proc machines using VSTT 2005 , you need to enable Server GC on QTAgent.exe.config, if you are using Controller/Agents OR VSTestHost.exe.config,  if you are using the Visual Studio IDE. The configuration looks like this:

<?xml version =”1.0″?>
        <gcServer enabled=”true” />
        <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
            <probing privatePath=”PrivateAssemblies;PublicAssemblies”/>

For a crisp explaination of how the GC functions and the difference between Server GC and Workstation GC; visit: Performance Considerations for Run-Time Technologies in the .NET Framework