Troubleshooting Load Tests

Article
02/04/2013

This topic lists the following common issues that occur when you work with load tests in Visual Studio Ultimate.

Unable to use SQL Tracing

Error occurred running test. (Computer xyz) could not access the result repository: Invalid object name 'LoadTestRun'

Unable to collect performance counters

LoadTestCounterNotFoundException Error

LoadTestResultsCollectorSlowException

LoadTestErrorLimitExceededException Error

Unable to access the load test results repository

Unable to Generate Expected Load

Load generation limitations on multi-core computers

Unable to use SQL Tracing

When you run a load test locally, with SQL tracing enabled, you might receive the following message:

Error occurred running test. Could not start SQL tracing: You do not have permission to run 'SP_TRACE_CREATE'

To use SQL tracing in a load test that is run locally on a computer that is running the Windows Vista operating system, you must be a member of the sysadmin role on the instance of SQL Server that is being traced. To fix this problem, a SQL Server administrator must add you to the sysadmin role.

Error occurred running test. (Computer xyz) could not access the result repository: Invalid object name 'LoadTestRun'

This error indicates that the load test database schema was not created. You can use Query Analyzer to run the LoadTestResultsRepository.Sql file located in <Visual Studio install folder>\Common7\IDE\ to create the database.

If you are using SQL Express, you can run "sqlcmd -S .\SQLEXPRESS -i loadtestresultsrepository.sql" at a command prompt in the directory listed previously.

Warning

The parameters are case sensitive. You must type uppercase S and lowercase i.

For more information, see How to: Create a Load Test Results Repository Using SQL.

Unable to Collect Performance Counters

The following list describes common issues for not being able to collect performance counters from a machine:

Firewall: Performance logs and alerts should be in the allowed program list in the firewall. Specifically, this is the firewall on the machine that collects performance counters. By default, the performance logs and alerts are not included in the firewall’s allowed programs list.
Permissions: The user account being used on the test controller machine should also be a member of one of the following groups on the machine that is collecting performance counters:
- Performance Log Users
- Performance Monitor Users
- Administrators
Service: Performance logs and alerts service should be running on the machine that collects performance counters. By default, the service is disabled.
Timeout: Timeout might occur if you are collecting counters from a remote machine. You can increase the timeout by adding the following key in the test controller’s configuration file.

In the folder C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, open the file VSTestHost.exe.config and add the following key, which sets a one minute timeout:
```
<appSettings> 
   <add key="LoadTestCounterCategoryReadTimeout" value="60000"/> 
   <add key="LoadTestCounterCategoryExistsTimeout" value="60000"/> 
</appSettings>
```

LoadTestCounterNotFoundException Error

This error occurs when a performance counter that is included in one of the counter sets in your load test is not found in the performance counter category that contains it. If this is a counter that you added to the counter set, the name of the performance counter is possibly misspelled. It is also possible that the performance counter no longer exists in the category because the performance counter has been removed in a newer revision of the software component that defines the performance counter. You can remove it from the counter set to correct the error without losing any useful data.

LoadTestResultsCollectorSlowException Error

This error indicates that the test controller was not able to collect performance counter results from all the computers in the specified sample rate for the load test. This can occur when there are many performance counters to collect from many different computers as specified by the counter set mappings for the load test. It can also occur when the test agent is running on the same computer as the test controller. You might be able to correct this error by increasing the sample rate for the load test.

LoadTestLimitExceededException Error

This error occurs whenever 1000 or more errors of the same type occur. It usually indicates that there is a problem with the test that is running under the load test. For example, if your Web performance test issues requests to URLs that are not found, you should correct the Web performance test to fix this error.

Unable to access the load test results repository

When you run a load test, you might receive the following message:

Could not access the load test results repository

One possible cause of this error is specifying the incorrect case for the parameter names when you use the SQLCMD command line utility to set up your load test results repository. The following code is a sample command to set up a load test results repository on a server named ContosoServer1:

SQLCMD -S ContosoServer1 -U <user name> -P <password> -i loadtestresultsrepository.sql

Warning

The parameters are case sensitive. You must type uppercase S, U, and P, and lowercase i.

For more information, see How to: Create a Load Test Results Repository Using SQL.

Unable to Generate Expected Load

A common issue when you run a load test is not being able to generate the load you expect. The following table lists some possible causes of this problem:

Maximum load is being limited by the think time or by the number of virtual users.	If think time is turned on it can limit the rate at which each virtual user can submit requests. For example, 5 seconds of think time per request yields a maximum of 0.2 requests per second per virtual user. You can try one of the following changes, in order of preference: Increase the number of virtual users for more realistic load generation. Increasing the number of virtual users usually requires more memory. Reduce think time. Turn off think time for maximum load generation. Caution Turning off think time can have a large impact on the test engine If you turn off think time, reduce the number of virtual users.
The proxy property of your Web performance test is set to "default".	Using "default" as the proxy setting in a Web performance test is convenient because it enables automatic proxy server detection. However, using "default" as the proxy setting can cause performance problems in load tests and will greatly reduce your maximum throughput. It is better not to use a proxy server when you run a load test. If a proxy server is required, specify the name of the proxy server instead of "default".
Application bottlenecks.	Remember, the load testing tool is designed to find bottlenecks in your application. If you have pages with high response times because of a database or CPU bottleneck, it will limit the number of requests per second that each virtual user can issue. Start with a small amount of load and make sure response time stays reasonable as you increase the load slowly. You can use the Response Time Goal property to set the maximum expected response time on each request.
The CPU, memory, or network of the Web server has exceeded its limit.	If the CPU, memory, or network of the Web server has exceeded its limit, you might not be able to generate the load you expect. It is possible that you have found the load limit of the server. You can increase the CPU, memory, or network of the Web server.
The CPU, memory, or network of the computer generating the load has exceeded its limit.	You might need more powerful computers, or more test agent computers, to generate the desired load.
The CPU, memory, or network of the database server (if applicable) has exceeded its limit.	If the CPU, memory, or network of the database server has exceeded its limit, you might not be able to generate the load you expect. It is possible that you have found the load limit of the database server. You can increase the CPU, memory, or network of the database server.

Load generation limitations on multi-core computers

When you run load tests on multi-core computers, load generation is limited as follows:

If the computer is running Visual Studio Ultimate the load generation is limited to one core.
If the computer is running Visual Studio Test Agent, the load generation is not limited; it runs on all cores and processors.

Troubleshooting Load Tests

Unable to use SQL Tracing

Error occurred running test. (Computer xyz) could not access the result repository: Invalid object name 'LoadTestRun'

Unable to Collect Performance Counters

LoadTestCounterNotFoundException Error

LoadTestResultsCollectorSlowException Error

LoadTestLimitExceededException Error

Unable to access the load test results repository

Unable to Generate Expected Load

Load generation limitations on multi-core computers

See Also

Tasks

Concepts

Other Resources

Additional resources