Troubleshooting Load Tests
This topic lists the following common issues that occur when you work with load tests in Visual Studio Team System Test Edition.
Unable to use SQL Tracing
Error occurred running test. (Computer xyz) could not access the result repository: Invalid object name 'LoadTestRun'
LoadTestCounterNotFoundException Error
LoadTestResultsCollectorSlowException
LoadTestErrorLimitExceededException Error
No Agent Machines Matched the Selection Criteria
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 Results Repository Using SQL.
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 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 load agent is running on the same computer as the 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 test issues requests to URLs that are not found, you should correct the Web test to fix this error.
No Agent Machines Matched the Selection Criteria
When you run a test on a rig, you might receive the following message:
No Agent Machines Matched the Selection Criteria
When a test is running on a rig, you can specify selection criteria for the agent computers that are connected to the controller. For example, you can specify that only agents with a specific operating system will be used to run a test. If no criteria are specified, then all the agents connected to the controller will be used to run the test. If no agents match the selection criteria, the test will not be run.
To fix the problem of no agent computers that match the selection criteria, follow these steps:
On the Test menu point to Edit Test Run Configurations and then click the configuration that is currently active.
Note
To find the configuration that is currently active, on the Test menu point to Select Active Test Run Configuration. The active configuration will have a check mark in front of it.
In the list box, click Controller and Agent.
In the Name and Value grid, delete criteria that exclude agents that you want to use to run the test.
When you are finished, click Apply and then click OK.
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 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:
|
The proxy property of your Web test is set to "default". |
Using "default" as the proxy setting in a Web 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 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 Team System Test Edition or Visual Studio Team System, the load generation is limited to one core.
If the computer is running Visual Studio Team System Test Load Agent, the load generation is not limited; it runs on all cores and processors.
See Also
Tasks
Troubleshooting in Test Edition
Troubleshooting Controllers, Agents, and Rigs
How to: Create a Results Repository Using SQL
Concepts
Considerations for Large Load Tests
Analyzing Threshold Rule Violations