Scalability Testing of Web Applications

This article describes how to test the web application scalability deployed in the Azure Kubernetes (AKS) service. Usually, most applications must comply with:

Meet the response time as determined by SLA. If there is no SLA before, then consider that the application response time must be very minimal proportional to the load.

For SLA (+ buffer) specified and the response time, the server uptime must be high

For testing, consider the hardware resemble production, including data, capacity or volume.

Application scalability testing must consider the following performance factors: –

• Time responds
• Throughput
• JVM use such as Heap, Non-Heap and GC Interval
• Use of network bandwidth
• Server activities including IO, users, and system use
• Disk read/write speed
• Similar hardware configurations resemble production use
• Knowing how tabulated testing the IstiDability of the software will answer, for example, the following questions:
  1. How many users can I add without affecting application performance?
  2. Will you add more servers to solve my performance problems?
  3. Will duplicate hardware allow me to double the number of users?
  4. The question above can be answered through various types of scalability testing, which is briefly described below:

1. Predictable scalability: keep static hardware and increase or reduces the volume of users to see if the performance is influenced proportionally to know the predictability of the system is called predictable scalability.
2. Horizontal Scalability: When the server is inadequate to handle the current workload, the process of carrying a new server to share the workload along with the server is currently called the horizontal scale or scaling.
3. Vertical scalability: When servers are currently inadequate to handle workloads, the process of replacing them with a higher capacity server is called vertical scaling or scaling.

All approaches above for scalability testing have their own advantages and disadvantages.

Preparing our tests Before starting tests, we must prepare a load with similar hardware configurations that resemble the production environment to handle the traffic that is in real situations.

Before we test scalability, we also need to find the application solving point by testing stress. With the results of a stress test, we can analyze how much the performance we achieve and when the application/server is damaged.

Let’s say we consider 10000 requests per second regarding the server breaking up the application, this will be the point of solving, and we can consider 80% of the request i.e. 8000 per second to become a standard threshold.

Based on this analysis, we must plan to match the application when utilization reaches this threshold. Also, it depends on the loading time/start-up application, including the provision of resources to start the application.

Scalability test plan

The following steps are followed to execute scalability testing:

1. Select the process or function that includes the end to end scenario or the most widely used to do a scalability test
2. Set the response time and other critical performance criteria according to SLA
3. Identify how to test scalability both with scripts or tools or several environments, and build the environment.
4. Make sure all tweaks or configurations or changes are needed before testing
5. Run the sample scenario to make sure everything works according to expectations and then run the planned test scenario
6. Run the load test
7. Analysis of results and generate reports

Carry out a scalability test

Objective: The application in the test will make a login request that internally directly directly for security validation and then lands into the application.

Here the goal is to reach 1 million requests that trigger applications in the specified time period to ensure re-briefing and logging into the application will be carried out with a maximum success rate and minimum response time using resources to the maximum.

System review – Simple settings will have a web application that is hardened in AKS, refers to a relational database.

1. Use the Azure event hub service with Kafka activated
2. Use the Azure SQL service

Horizontal Scaling – Automatic Scales Enabled By Default with 4 Pods and Scales with 1 Pod

The scaling threshold – when the CPU ultrasound exceeds 40% of POD, the automatic scaling will kick and 1 new pod will be made. No scaling filters based on memory resources applied

1. Database load test – to identify a slow query and lose optimization in the DB scheme such as other DB indexes and configurations
2. Application Load Test – To identify obstacles in the application code related to optimized execution, memory usage, and other resource utilization.

First, the test is run on the database. Test 1 describes DB load tests to identify initial obstacles, which use data insertion to DB.

Test 1: The initial test starts with the insertion of 1K #Rows and takes a total of 14 hours.

The problem identified: observed that certain DB calls take a significant time, and in detailed analysis identify the query that causes delays and make the following changes:

Add the right index to make the query giving faster results

Test 2: tested with the installation of 2K #Rows and identify several more obstacles even though the throughput improves.

The problem identified: observing that DB calls still take a significant time, make the following changes:

tweak query in DB so the insertion will occur much faster

Test 3: Test 1 again after tweaks above and #rows is entered now in 56 seconds, which is a dramatic performance increase !!

Test 4: Now we have optimized DB calls, we increase the number of line insertions to 50K to validate if DB will maintain and produce increased results with data size. We observed that test 4 with 50Kline insertion produced a good throughput of the DB perspective.

Now we have optimized DB size, we move the testing phase to application performance. Here the scalability test will do 1 million requests within the specified time to identify problems associated with application logic or JVM or any cloud configuration.

During the test, we identified that requests failed on the server-side. After analyzing this failure, we identify that the existing configuration is not suitable for testing and optimizing it.

The same test was repeated several times to identify further problems if any. After several test cycles, we do the following optimization to improve application performance.

Configuration of AKS AUTS -40% CPU use. If the CPU usage exceeds 25% of the POD, then the new POD will be added automatically.

1. Increase the number of partitions in the Azure event hub service
2. Database level increases from S2 to S4
3. Enhanced to java 10 for better resource management in docker containers
4. Optimized default docker container value

After optimization above, we can reach 1 million requests within 1 hour. To reach 1 million this request, we have to measure #USers to 200 to 2 virtual machines.

We also have to ensure that requests do not hit the server continuously without thinking of the time, because it will cause failure on the server side during validation.

Conclusion

In this blog you will learn how you can do the scalability testing of your web applications. If you find this blog post informative then share this with others also.

Coteriesoft – Best software company in Lucknow. If you want any type of software solutions then you can connect us at any time.