Following our previous post on planning a load test, we are throwing in more points that you should consider when planning for a load test.
- What is the total user base? What is the concurrent user base? – Now after working the maths out, do you required a load test. Example, is a 5 concurrent user base an effective load test? Is it worth the effort to generate a script that emulates 5 concurrent users? Your customer may want you to run a load test for 5 users even though it is not effective to run that kind of load test. However, if it is in the contract, you may have obliged it. If they are willing to pay for that service, then it’s a plus point!
- Do the available load testing tools support your system in a load test? – A very strange question to ask. Most tools are unable to support asynchronous application and map applications. Either you may have to purchase more licenses to run the load test like in LoadRunner, find alternative sources or write scripts to emulate the load. There are multiple ways to run a load test however may require additional effort (which translates to additional time). Most tools are useful in coordinating and reporting which your scripts may not be able to achieve.
- What is the environment that you will be conducting the load test? – At times, your load test may be conducted in a scale-down production environment which you may know. The load test results may not be a good representation of the true performance of the load test. However, most of the times, running in production is a no-no and it is good to align everyone’s (stakeholders, customers, etc.) expectation of the load test.
- Where do you want the load to be generated to? – For a web application, there are multiple layers that you can access the system. You can access the normal URL that can be the virtual IP address from a central web server. You can enter at the load balancer or the web server layer. Lastly, you can enter at the application server layer. Where you want the load to enter can help you determine the layer that can be causing the performance problem. By stepping up from the application layer, you can determine stage-by-stage the layer as the source of bottleneck.
- What do you want to monitor? – There are so many things that you can monitor in an infrastructure. Which one do you want to focus on your analysis effort on first? Do you want to monitor all sub-systems or target your effort to the most possible source such as the database? Setting up monitors takes effort. What’s more tedious is the effort required to analyze the monitoring results that you have collected! Therefore, do take note and factor the duration and effort!
- Do you know the backbone network infrastructure? – This information is usually not available to a load tester. But if you know this, you can least prepare your team that the load test will bound to meet (or not bound to meet) performance issues during the load test. They can be ineffective load balancing, small bandwidth available, invisible proxy that limits bandwidth, etc. If you do not know this information, it is best to work on those you know such as the method previously mentioned by running the load test stage-by-stage.
- Is your load test conducted in a wireless environment? - A wireless environment may be limited by the number of access point and the bandwidth available per wireless network. You need to know if the wireless will become a potential bottleneck in the amount of clients that can be generated into the system before your load test.
- Do you have a base set of data to use in a load test? – Most often after a load test, the data in a database will likely be messed out. Therefore, it is advisable to create a backup of a working set of data in the database for you to reload after each load test.
