When it comes to theuser experience, there is nothing more important for users than experiencing smooth and stable functionality of web applications. These aspects are like the foundational parts of any website or web application, and essential to its success. However, as more users start accessing the application, more resources are used, and typically, the slower it becomes. It is an awful experience for users as they started getting weird system error messages, timeouts, slow page response, and server errors. To save us from all these issues, we need to take functional testing to the next step and carry out non-functional tests, such as load testing or stress testing, which validates whether the application can handle large number of concurrent users, as well as determine how the system responds as traffic scales.
Before beginning your load testing journey, it is important to understand best practices on how to simulate stress tests on application, which is as close to as the production environment. Basic performance testing strategy includes answering questions like the following:
- Number of concurrent users required for our load test.
- Simulating real user test scenarios.
- Geo-distributed virtual loads.
- Ramp up and ramp down periods.
- Test duration.
Let us discuss each one of these and understand why they should be in our checklist before we run our load tests.
Concurrent Users Required for Load Testing
Before setting up a test that reflects close to real user behavior, we must spend some time to figure how many concurrent users are needed to simulate for our test. Concurrent users define how many users will be browsing our website or web application and will be performing transactions over a specific time period. Traffic to your sites and applications likely ebbs and flows throughout the week, but in order to properly test your sites and applications, you will want to configure your test to at above peak traffic times. But how do your correctly find the correct number of concurrent users?
We can use web analytics tools to determine current traffic statistics on our website with details to look for like count of visits, duration of sessions on the website. Google Analytics and many other analytics tools can provide sessions metrics that your website has per a regular timestamp and the average session duration, and time spent by users on the website. We can use below formula to estimate the number of concurrent users:
Concurrent users = Hourly Sessions x Avg. Session Duration (in minutes)/60
If we don’t have web analytics data, we can use the expected number of user visits to calculate the number for concurrent users:
Concurrent users = Number of expected visits per minute * Visit Duration (in minutes)
For more information and tips regarding configuring current users, visit our Knowledge Base and read our article about calculating concurrent users from web analytics.
Simulating Real User Test Scenarios
As we are ready now with concurrent users, we need to find the frequent and high traffic test scenarios to be part of our stress tests. Keep in mind that it is not necessary to use many scripts for every situation. Typically, you will find that only a small number of use cases are needed to determine the actual load for all your transactions.
Once we have determined the relevant level of concurrent users, we should choose the appropriate load testing task simulation approach, based on the application under test.
Load Testing Web Applications and Web Pages
For simulating user scenarios and transactions for web applications and websites, we need to script the user journeys for simulating our test scenario. For this use case, we can use the EveryStep Web Recorder, which records our browser interactions and creates a script which can be used for our load test. The EveryStep Web Recorder is easy to use, but capable of scripting the most complex scenarios. Additionally, users can set delays, edit keywords or field variables, set network throttling, and much more. To learn more about editing a script with the EveryStep Web Recorder visit our Knowledge Base for more information.
For executing load tests for web pages, teams can use the Web Page option in LoadView, which begins the process of testing web pages with concurrent users.
Additionally, the LoadView platform allows development teams to load test APIs and streaming media. For more information on API and streaming media pages, visit our Products page.
Geo-distributed Virtual Loads
As you probably are already aware, network latency has a huge impact on websites, so while our stress test we should not be neglecting the concurrent users to be geographically distributed load, so that we simulate the same behavior as we see in the production environment, as well as check response times for users located far from your data center. Consider a web page that downloads 2MB of content during refresh and 10ms for each back-end request. The load time in your data center will be less than five seconds because of proximity and low latency.
On specific locations abroad, such as Asia, with a latency of 200ms, the response times of this website will be five seconds for the back end, and over 200ms for the network transfer. We should not make a mistake and measure response times only inside our data center. We can use LoadView here which gives a broad range of load injection machines around the world. Out of all these options we can select all those who represent the usual location of our customers.
Ramp-up Period Between Scale
Usually, our websites have scattered concurrent users at different times of day, we have few of the peak hours during which we have the highest traffic. We should be using the same approach to scale out and stress test applications using the same ramp up strategy. LoadView gives you the ability to set your ramp up, hold times, and at what rate you need to ramp down.
Load Testing Duration
Test duration is a really important factor during load testing for the sole reason to provide enough time to the application so that it generates realistic results with details like response time, throughput and if any cache mechanism is present in the application, it gets cached during our ramp-up period. To decide the test duration, we need to look forward to our test scenario and requirement. We can consider following cases while deciding the test duration for a load test:
- We need to make sure that each request/test step should run for at least 10 times. We should keep test duration higher for lengthy scenarios as compared to smaller ones.
- We would also need to decide what type of load test are we planning to execute because we may need to set longer time duration if we must verify application’s stability and performance characteristics over an extended period.
- Always keep a few buffer minutes additional for warming up the application as mentioned above.
Wrapping Up: How to Properly Simulate Traffic on Websites or Web Applications
As you can see, there are many factors that need to be taken into consideration before setting up and running your load tests. Ensuring your web application and sites perform flawlessly for your customers is critical to the success of your business. The LoadView platform was designed in a way that will quickly and easily walk you through the step-by-step process for setting up your tests. The platform can set up real-world scenarios and help gauge performance from multiple locations.
Sign up for the LoadView free trial and get free load tests to start, or sign up for a LoadView demo. One of our performance engineers will walk you through the whole solution and answer any questions about the platform or answer your specific questions about the load testing process.