Export (0) Print
Expand All

Troubleshooting Load Tests

This topic lists the following common issues that occur when you work with Load tests in Visual Studio Team Edition for Testers.

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

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.

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. You must type uppercase S and lowercase i. For more information, see How to: Create a Results Store Using SQL.

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.

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.

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.

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:

  1. On the Test menu point to Edit Test Run Configurations and then click the configuration that is currently active.

    NoteNote

    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.

  2. In the list box, click Controller and Agent.

  3. In the Name and Value grid, delete criteria that exclude agents that you want to use to run the test.

  4. When you are finished, click Apply and then click OK.

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

You must type uppercase S, U, and P, and lowercase i. For more information, see How to: Create a Results Store Using SQL.

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:

  1. Increase the number of virtual users for more realistic load generation. Increasing the number of virtual users usually requires more memory.

  2. Reduce think time.

  3. Turn off think time for maximum load generation.

    Caution noteCaution

    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 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.

Community Additions

ADD
Show:
© 2014 Microsoft