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.
Test
project 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: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.