When we deploy to a production environment, we want to make sure that it can handle the load that we are going to put on it with the application. We are going to build a load testing suite that allows us to test our data access for this purpose.
For this recipe, you will need the load testing tools from Visual Studio. These are part of the load testing feature pack which is available to the Visual Studio Ultimate users with active MSDN accounts.
We will be using NuGet Package Manager to install the Entity Framework 4.1 assemblies.
The package installer can be found at http://www.nuget.org/.
We will also be using a database for connecting to the data and updating it.
Open the Load Testing against a Database solution in the included source code examples.
Execute the database setup script from the code samples included with this recipe. This can be found in the DataAccess project within the Database folder.
- We are going to take our already prepared performance tests and use them in a new load test by adding a load test to the
Testproject and naming the scenario BasicDataAccess in the wizard. Select the Use normal distribution centered on recorded think times option, and change the Think time between iterations to 1 second, as shown in the following screenshot:
- We are going to simulate 25 users, for a constant load, as shown in the following screenshot:
- Set the Test Mix Model to Based on the total number of tests, as shown in the following screenshot:
- Add both existing tests to the Test Mix at 50% of load, as shown in the following screenshot:
- We skip Network Mix and Counter Sets for this test, and on Run Settings, we set a 10 minute duration for the test run, as shown in the following screenshot:
- Finish the setup, and you should get the following screenshot. Click on the Run Test button in the upper left corner as follows:
- When you open the test, you will get a very complex screen. The left panel holds the counters that you can drag onto the graphs to the right to monitor system and test performance. The graphs hold the these values. The table on the bottom right holds the numeric values that drive the graphs, and the list on the bottom left holds the number of run and completed tests. It should take a while for the first test to run due to the setup scripts, but after that it should run pretty fast:
This load test spins up threads across as many processors as it can to simulate multiple users hitting the application at the same time. This in turn creates many connections to the database. This flood of connectivity and processing would have been impossible except by full production load in the past, but is now a simple setup to get. We are able to test not only our database connections this way, but also other internal pieces of our application that may come under the load. This allows us to identify bottlenecks and resolve them before they cause a production issue.
Load and performance testing are tightly coupled, and should be used in conjunction. The two styles of load testing need to be leveraged on our application in the same combination.
Stress testing is one of the two main ways to load test an application. This is the test in which we slowly increase the amount of load on a system until it fails. This does two very important functions for us. First, it identifies the initial point of failure, or the bottleneck. Second, it allows us to view the pieces of software on the value of their scalability, and work to increase the throughput and handling of those pieces that do not function well. This will help us ward off problems before they bring our boss to our desk at 4:45pm.
Real world simulation is the second of the two main ways to load test an application. This puts a slightly higher than expected load on the system to see how the performance and functionality will handle the load. This is an assurance that the system will function day-to-day at an acceptable level. We are not hunting for bottlenecks with this type of testing, but merely making sure we have met the expectations and that we are fully prepared to hand over this software to our customers without the fear of a major performance issue.