There is nothing more important in the application than its smooth and stable functional aspects of a software application. These are like the foundational parts of any website or web application essential to its success. However, as more users start accessing the application, 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, we need to carry out load testing which validates whether the application can grow multi-fold and is able to scale with new customers. Before starting to load tests we should understand best practices on how to simulate stress tests on application, which is as close to as production setup.

If we have no experience performing load tests, the chance is very likely that we will run into pitfalls and may not reach our goals. However, if we can use some of the strategies listed below, and we would be able to make a good step towards responsive and reliable application.  Basic performance testing strategy includes answering questions like the following:

  • Count of concurrent users required for our load test.
  • Simulating real user test scenarios
  • Geo-distributed virtual loads
  • Ramp up period between scale
  • Test duration

Let’s discuss each one of these and understand why they should be in our checklist before we run our load tests.

 

Count of Concurrent Users Required for Load Testing

Before setting up a Test Load that reflects close to real user behavior, we must spend time to find the number of concurrent users required to simulate our test. Concurrent users define how much users will be browsing our website and will be performing transactions in a random way.

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)

 

Simulating Real User Test Scenarios

As we are ready with concurrent users, we need to find the frequent and high traffic test scenarios to be part of our stress tests. But we do need to keep in mind that there is no need to implement a high number of load testing scripts for your application. Often 20 percent of the use cases generate 80 percent of the total transaction load.

Once we have selected the relevant user interactions, we should choose the appropriate user simulation approach based on the application under test:

  • Rest APIs: To stress test web services and REST APIs, we can use LoadView REST API load test service which helps in easy addition of all APIs with user friendly ,
  • Web applications: For web applications, we need to use the website user journey for simulating our test scenario. For this use case, we can use EveryStep Web Recorder, which records our browser interactions and creates a script which can be used.
  • Websites: For websites, we could use the Web Page option in LoadView, which starts load testing of a web page with concurrent users.

 

LoadView test setup

 

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 production and also check response time for users present far from data centers. 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.  Even marketing campaigns, sales, and promotional offers can have a huge impact on the number of users arriving on our website. Typically the user lands slowly in the morning and it reaches a high over a full business day. It’s crucial for the success of our load test that we model a realistic execution plan. LoadView has various features that allow us to model a real-world load curve. We can specify how fast the user should be ramped up, how long a particular number of users should simulate the load, and also at what rate they should be ramped down. The execution plan feature of LoadView gives you full flexibility to model a realistic load test scenario.

 

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 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 have to verify application’s stability and performance characteristics over an extended period of time
  • 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 $20 in load testing credits to start or sign up for a LoadView demo.  One of our performance engineers will walk you through the whole process.