Cant read performance counter categories for computer ‘…’

Or you might not get any values when running the load test and then get the following error in the Test Results

The performance counter category ‘Processor Information’ cannot be accessed on computer ‘I-NB160′ (Category does not exist.) ; check that the category and computer names are correct.

To troubleshoot these issues I’ve found the following tips really useful. You have to check them in the machine from which you are trying to collect the counters. My test rig was configured with 1 controller and 2 agents using Windows Server 2008 R2.

• First, make sure that the user the Controller Service is running under is part of the Performance Monitor Users group. Additionally, make sure that the user under which Visual Studio is running is also part of this group.

  
  

• Then make sure the Performance Logs and Alerts and the Remote Registry services are started.

  

  

For more details, check these two blog posts I’ve found around this subject:

• http://blogs.msdn.com/b/edglas/archive/2008/11/19/reading-performance-counters-on-vista-and-server-2008-machines.aspx
• http://blogs.msdn.com/b/rubel/archive/2011/06/04/issues-while-collecting-counters-during-load-test-execution.aspx

If you want to learn more on how to configure a Test Rig, check my previous post.

In this post I’ll walk you through the steps to setup a Test Rig using Visual Studio 2010. The Test Rig configuration I’ll be implementing is composed of 1 controller, 2 agents, and a separate machine with Visual Studio 2010 Ultimate that connects to the Test Rig for running the tests (Development Machine). I’ve used Windows Server 2008 R2, but you can use Windows 7 Ultimate as well.

In particular, I’ll show you how to configure the Test rig in a Workgroup configuration, meaning no central Windows domain is present and thus the machines are not joined to any domain. It is important to know that in this configuration local users from different machines, with the same name password are treated as the same users. To better explain this I’ll quote this explanation from a post linked below:

When MACHINE1UserXYZ tries to authenticate to MACHINE2UserXYZ, if the passwords are the same, then on MACHINE2, the UserXYZ is authenticated successfully and is treated as MACHINEUserXYZ. Note the last sentence. The user MACHINE1UserXYZ is authenticated as MACHINE2UserXYZ if the passwords are the same.

If you want more details on some of the procedures, check the following articles I’ve used as the main reference for this post. They are quite old, but they still apply to Visual studio 2010.

• http://blogs.msdn.com/b/edglas/archive/2007/02/17/load-agent-and-load-controller-installation-and-configuration-guide.aspx
• http://blogs.msdn.com/b/dgorti/archive/2007/10/02/vstt-controller-and-agent-setup.aspx

Prerequisites

Before starting the agent and controller, check that you have the following prerequisites:

1. One administrator account in all Controller and Agents machines. This account will be used to run the setup on each machine. If possible, try to use the same administrator account name and password in all the machines, it will save you some time.
2. Install SQL Server (Express or Full) in the Controller Machine for the Load Test Results Store.
3. Download the Visual Studio Agents 2010 ISO installer, which includes the Test Agent and the Test Controller installers as shown in the following picture.

Controller Installation

Let’s start by installing the Controller.

1. Login to the Controller with an administrator account (meaning member of the Administrators local group).
2. Open the ‘Local Users and Groups’ manager. To do this, open the Start menu, and type lusrmgr.msc in the search line and press ENTER. Create these three accounts:
   • A local account for the controller service. Let’s name this account ControllerService.
   • Another local account for the agent service. Let’s name this account  AgentService.
   • A user with the same name and password than the account running Visual Studio in the Development Machine (i.e. user logged in into Development Machine). For this post I’ll use my account sdurandeu. In my configuration for writing this post, this account was actually a Windows Domain account. However, as the controller machine is not joined to the domain I created a new account with the same name and password.
     
     
3. Run the Test Controller installer (see prerequisites for link). Set ControllerService as the account for running the test controller. Leave localhost for the load testing database to point to the local SQL Server.

   
   

4. Click Apply Settings and make sure all steps succeed.

   
   

5. Re-open the Local Users and Groups manager. To do this, open the Start menu, and type lusrmgr.msc in the search line and press ENTER.
6. Open the TeamTestAgentService Group. Add the AgentService user account.

   
   

7. Finally, open the TeamTestControllerUsers group and add the ControllerService account and the user running Visual Studio. This will allow the user running Visual Studio to connect to the Test Rig to run tests (not manage – see next step).

   
   

8. Finally, add the user running Visual Studio (in this case my account, sdurandeu) to the TeamTestControllerAdmins and the Administrators group. This will allow you to manage the test rig from Visual Studio (turn off/on agents, restart services, etc.).
   Actually, in the tests I’ve made I could restart the rig only by adding the sdurandeu user to the Administrators group, it’s seems not necessary to add the user to the TeamTestControllerAdmins group.
   
   
   

The Controller is ready, now let’s configure the Agent.

Agent Installation

Repeat these steps for each agent machine.

1. Login to the Agent machine with an administrator account (meaning member of the Administrators local group). If you are not using the same administrator account user name and password, you need to make sure that the user running the setup is a member of local Administrators group and a member of the Controller’s Administrators group.
2. Open the ‘Local Users and Groups’ manager. To do this, open the Start menu, and type lusrmgr.msc in the search line and press ENTER. Create these three accounts:
   • A local account to allow the controller service to connect to the agent. Let’s name this account ControllerService.
   • Another local account for the agent service. Let’s name this account AgentService.

     

3. Run the Test Controller installer (see prerequisites for link). Set AgentService as the account for running the test controller.

   
   

4. Click Apply Settings and make sure all steps succeed.

   

Connecting to the Test Rig from Visual Studio

Before running the load test from Visual Studio, you need to make sure the test rig is fully operational. To do this, open Visual Studio 2010 Ultimate and go to Tests | Manage Tests Controllers. Type the host name or IP Address of the test controller and make sure all agents are in Ready state as shown below.

If you get the following error (‘Not all the agents are ready. To manually check the status…’) , an easy fix is to disable the Windows Firewall in the controller and agents. It’s kind of a brute force approach, but might help getting things ready fast. If you want to perform deeper troubleshooting check the following articles:

• Troubleshooting Guide for Visual Studio Test Controller and Agent

• Troubleshooting Controllers, Agents, and Rigs (MSDN)

  

One thing that worked for me is to enable Firewall File and Printer Sharing Inbound Rules in the agent machines.

Hope you find it useful and don’t hesitate to contact me if you have any questions.

Without getting into the technical details, the error message you see (‘Script is disabled. Click submit to continue’), is because the Visual Studio Test Engine does not support JavaScript and thus the automatic POST of the SAML token into the Relying Party (i.e. your application) does not work (more details here).

In these cases, before actually being able to perform a successful request that hits your SharePoint application, you will need to perform an explicit authentication request to ADFS to get a valid Authentication cookie (AKA FedAuth cookie) and send this cookie in all subsequent requests. This will make the request an ‘authenticated request’, avoiding the redirection to ADFS and thus the error above. Throughout this post you will learn how to implement this flow within a Load Test by creating a Login Web Test that authenticates Virtual Users in ADFS.

Disclaimer: To keep things as short as possible I won’t get in Visual Studio Load Testing or ADFS details. I will assume that you’ve used VS Testing platform before and you are somehow familiar with ADFS. If you want VS Load Testing documentation this post has a comprehensive set of links. Additionally, I’ve also found this Visual Studio Performance Testing Quick Reference Guide a gem; it is a bit more advanced, but very complete, covering lots of specific cases. Finally, notice that I will  assume some ADFS and SharePoint configurations, but I’ll try to make them explicit.

1. To start I’d suggest that you use Fiddler to inspect a normal authentication flow in your SharePoint application. Assuming ADFS is configured for Windows Integrated Authentication, you should get a set of redirections, be prompted for your username/password, and arrive to your target application with a valid FedAuth cookie. Check the last request to ADFS and take note of the wa (the operation name), wrealm (your application identifier) and wctx (in this case the app return URL after ADFS sign in) querystring values. Make sure you copy the values as they are, including the URL encoding.

2. Now let’s switch to Visual Studio. On a new Web Test, let’s add a new request to the ADFS Integrated Login URL (…/adfs/ls/auth/integrated) passing the wa, wtrealm and wctx values you’ve obtained as QueryString Parameters. Then add three Form Field extraction rules for the following values: wa, wctx, wresult. Make sure the corresponding Context Parameters are created in the Web test.

This will perform a Windows Integrated authentication request simulating part of a normal federated authentication flow. After Visual Studio provides valid AD credentials (configured in the Web Test properties as shown below), ADFS will return a valid SAML Token in the wresult form field of the response. With the Extraction Rules, Visual Studio will extract the SAML Token value and place it the wresult Context Parameter for using it in the next request you will create (wa and wresult will also be extracted and re-sent).

3. Now you need to add another request to the Web Test for posting the SAML token to the SharePoint application. To do this, you should create a request to the Sharepoint STS URL (/_trust/) under your SharePoint application, passing the wa, wctx and wresult context parameters (the {{…}} pattern indicates the use of context parameters values). The response of this request will have a valid FedAuth cookie, which will be automatically stored by Visual Studio in a cookie container and sent back on subsequent requests to the application under test.

4. It’s also a good idea to add a final request to the application under test to make sure authentication worked as expected. Ideally, a Validation Rule should be added to ensure that the request is indeed reaching the application and not bouncing back to ADFS for authentication. For example, you can add a validation rule that parses some user identifier value present in the page.

5. Let’s now run the Web Test stand-alone to make sure it’s working as expected.

6. Good, you now have a Visual Studio Web Test that performs login with ADFS and gets back a valid FedAuth cookie. So let’s see how this can be used within a Load Test. When creating a Test Mix you can specify an Initialize test, which is run by each Virtual User before any of the tests in the Test Mix are executed. This way each Virtual User will first login in ADFS and get a valid FedAuth cookie before executing other Web Test to add load to your application. All subsequent load test requests performed will hit your application directly, without redirecting to ADFS and thus seeing the error from the beginning of this post.

Please notice that if the testing time exceeds the validity period of the FedAuth cookie all the Web Tests of your Load Test will start to fail. The expiration time of the FedAuth cookie in SharePoint is set to 10 hours by default, but in your environment this might differ – check this thread with more information on how to check it.

Thanks to Rodrigo Molinas (@romolinas) and Sebastian Ballarati (@sballarati) for their contribution in the code for this post.

Wouldn’t be nice if this was automated? Fortunately this can be easily achieved through the use of a custom Load Test Plugin (ILoadTestPlugin) and a configured Threshold. (Custom load test plugins were improved in VS2008SP1 and are also available in VS 2010, used in the creation of this blog post.) This will save you (the Tester) the trouble of having to manually monitor the load test and stop it when the threshold is exceeded.

Let’s take a look at how this can be implemented in code:

Creating a Load Test Plug-in that stops the Load Test when a threshold is exceeded

Load Test Plug-ins allow custom code to be executed when a load test starts, ends, or when a threshold was exceeded, among other events. We’ll create a Custom Load Test Plug-in that attaches itself to the ThresholdExceeded event and stops the test.

1. Create a Class Library project.
2. Add a reference to the Microsoft.VisualStudio.QualityTools.LoadTestFramework assembly.
3. Create a class named CustomLoadTestPlugin and complete it with the following code (VS2008 and VS2010):

   using System;
   using Microsoft.VisualStudio.TestTools.LoadTesting;
   
   public class CustomLoadTestPlugin : ILoadTestPlugin
   {
       private LoadTest test;
   
       public void Initialize(LoadTest loadTest)
       {
           if (loadTest == null)
           {
               throw new ArgumentNullException("loadTest");
           }
   
           this.test = loadTest;
   
           loadTest.ThresholdExceeded += new EventHandler<ThresholdExceededEventArgs>(OnThresholdExceeded);
       }
   
       void OnThresholdExceeded(object sender, ThresholdExceededEventArgs e)
       {
           if (e.ThresholdResult == ThresholdRuleResult.Critical
               && e.CounterValue != null
               && e.CounterValue.CounterName == "Avg. Test Time")
           {
               this.test.Scenarios[0].CurrentLoad = 0;
               this.test.Abort();
           }
       }
   }

4. Build the Load Test Plug-in solution

Note: If you’d like to get more information about creating a Load Test Plug-in, see the following link.

Using the Custom Load Test Plug-in

1. Open the Load Test Configuration (.loadtest) you’d like to modify.
2. Using Solution Explorer, add a reference to the Load Test Plug-In (either to the Load Test Plug-In project or to the compiled assembly).
3. Add a Compare Constant threshold rule on the Avg. Test Time counter. To do this, Expand the Counter Sets | LoadTest | Counter Categories | LoadTest:Test element, right click on the Avg. Test Time counter and select Add Threshold Rule.
4. Add the Load Test Plug-In to the test run. To do this, right click on the Load Test Name (the top element) and choose Add Load Test Plug-in. On the window that opens, select CustomLoadTestPlugin and hit OK.

   

5. That’s it, you should now run the Load Test and see if it stops after your configured threshold.

Hope this saves you time. If you’d like to learn more ways to extend Visual Studio Load Testing, check Bill Barnett’s  article.

Related Articles

• Visual Studio 2010- How to create a Performance Data Collector

Happy testing!

In the other presentation I will join Federico Boerr and together we will try to demystified performance and load testing based on real world experience.

Since the audience will be half students and half professional developers, we decided to do both presentations in a extremely pragmatic fashion, showing tips & tricks. The deck of one of the presentations has just 3 slides! I will post them after the event, but here you have a preview:

Presentation (3 – 4 PM): 14 rules for web app performance improvement	Presentation (4:15 – 5:15 PM): How To: Perf and Load Testing

On the other hand, Southworks is one of the sponsors of the event and several other southies will be presenting as well (actually 7 presentations, wow!):

• Johnny and Lito about the Microsoft Data platform with SQL (they will do the demo that Southworks prepared for BillG KeyNote at TechEd Orlando 2008)
• Beto y Ezequiel Jadib will do a dev + IT talk on application health monitoring
• Martin Salias on his usual and great dynamic languages talk (Python on .NET)
• Angel Lopez is covering one of the speakers and will do one of our favorites topics: MS Robotics Studio
• Augusto Alvarez on IIS7

Southworks will have a booth as well, so feel free to stop by for some geek talks!