Scalability testing lets you determine how your application scales with increasing workload.
Suppose, your company expects the six-fold load increase on your server within the next two months. You may need to increase the server performance and shorten the request processing time to better serve visitors. If your application is scalable, you can shorten this time by upgrading the server hardware, for example, you can increase the CPU frequency and add more RAM. Also, you can improve the request performance by changing the server software, for example, by replacing text-file data storages with SQL Server databases. To find a better solution, first, you can test hardware changes, then software changes and after that compare the results of the tests.
Scalability testing can give answers to the following typical questions:
How do hardware and software changes affect the server performance?
Is it possible to increase the application’s productivity by upgrading the server hardware?
Creating a Scalability Test
Normally, scalability testing is performed as a series of load tests with different hardware (or software) settings while keeping other testing environment conditions unchanged. When you perform scalability testing, you can vary the CPU speed, the number and type of servers, the amount of available RAM, and so on.
Record one or more user scenarios.
(Optional) Modify the recorded scenarios. For example, you can provide scenarios with variable data by replacing hard-coded parameters of requests with variables. See Editing Recorded Requests.
Verify the scenario to make sure that the recorded requests are played back correctly. See Verifying Scenarios and Tests.
Create a test with the desired number of virtual users and configure virtual user settings - the scenarios that various users will run, the user bandwidth, browser and so on. For more information, see Creating and Configuring Load Tests.
(Optional.) You can also specify additional settings that allow you to estimate the performance of the tested web application. For example, using these settings you can specify the maximum amount of time that LoadComplete can spend on downloading the tested web pages. Therefore, each time the page load time or the time to first byte exceeds the specified value, LoadComplete posts an error to the test log. For more information on these settings, see SLA Settings.
Run the test. LoadComplete will simulate user requests.
Make changes to the server software or hardware. For instance, you can improve database access algorithms, employ data caching or upgrade the CPU and RAM of the server computer.
Repeat the series of tests specifying the same number of virtual users as in the previous test.
On the Graphs page, you can monitor the test execution. The Processing time metrics and Transfer speed metrics will provide clues on whether the site can be scaled.
For instance, the following image shows the server performance at 15 concurrent users.
As you can see from the graph, it certainly has a few bottlenecks and needs some optimization. To find the cause of a bottleneck, you can analyze your server application with special tools like SmartBear’s AQtime.
In the given case, the delay occurred due to non-indexed database access and redundant calls to the server. After optimization, the average response time and the overall test time have been drastically reduced.