Learn JMeter in 5 Hours

Start Learning
Slack

Run massively scalable performance tests on web, mobile, and APIs

Load Testing a Real-Estate App with BlazeMeter

Mobile app testing has become integral to mobile app development today. With numerous devices and OS versions, it is extremely important to employ tools that enable comprehensive testing of your mobile app. Being a popular mobile app development company, we get many app development requests. Each app is different and therefore the performance testing requirements vary a lot.

 

While a lot of people use native tools such as JMeter, load testing your app on a cloud-based platform provides important advantages. Here at OpenXcell we employ BlazeMeter to accomplish our performance testing goals.

 

We chose BlazeMeter because of its abilities to test from multiple IPs within its distributed network. This is important because many apps are conceptualized around business models that attract concurrent traffic from different geographic locations. Testing from a single IO might confuse your AWS server and it might pick up a DoS attack. BlazeMeter also enables quick performance testing of APIs, throughput control, test scheduling and can be integrated with New Relic.

 

In this post, I will share a few test insights from a property listing app we are currently working on. The app enables end users to search for properties within a given area, and to mark favorite and desired properties. Each property is linked to a specific broker, and users can call the broker from the app UI itself through a native dialer that pops up. The entire system also comes with a backend CMS which brokers can use to input their data into the system.


Load Testing for 500 Concurrent Users

 

The app owners wanted to examine 500 concurrent users generating 10,000 requests.

 

To start off, we tested the app for 50 concurrent users. A total of 1,928 requests were generated with an execution time of 20 minutes.

 

The first test showed that a number of web services encountered errors. The throughput was two hits/sec. Some of the slowest services yielded response time of more than 127,000 milliseconds, which is too slow.

 

Slowest Web Services:

 

throughput indicates the speed and rate of web services response, blazemeter

 

throughput indicates speed and rate of web services response, blazemeter

 

 

 

 

 

 

 

concurrent users and response time, blazemeter

 

We also found a total of 24 types of errors encountered by a number of web services within the app.

 

blazemeter error report

 

For the app to function smoothly for 500 concurrent users, these issues had to be examined and removed. We figured we need to optimize many web services and also set a new server configuration for the app.
 

First of all, we troubleshooted glitches with Web services.
 

1. We removed a number of subqueries for faster execution of the services.

2. We cut down on Joins which significantly reduced many services’ execution time.

3. We made changes so that the required column gets called.

4. Our developers opted for indexing on multiple tables.

 

Second, we configured the Web Server.

 

We also felt a need to increase the server configuration, so we shifted from a medium instance to large instance with 4GB of RAM and dual-core processor.

 

Right now we are running a large instance to test an identical application.

 

test run, blazemeter

 

After making these changes, we managed to massively bring down the response time of the web services. We achieved 0 error rate for 720 concurrent users, which is far more than the 500 users previously decided upon.

 

Each user generated an average of 14 queries calling a number of web services. This added up to more than 10,000 queries that were efficiently handled by the server.

 

Improved throughput and response time:

 

improved throughput and response time, blazemeter

 

 

The new Average Response Time stood at 493 milliseconds with no errors registered at all. Server latency which was non-uniform in the previous case, was also reduced and lead to a uniform and fast response time.

 

concurrent users and response time, blazemeter

 

All the web services behaved normally and responded to the queries with an average response time ranging from 0.3-0.4 seconds with 0 error rate.

 

Some webservices from the final report that shows improved execution time:

 

improved webservices execution time, blazemeter

 

To conclude, a property listing app might attract a significant number of concurrent users. Therefore it is extremely important for developers to be able to test the application and its respective web services with a predetermined number of concurrent users. BlazeMeter gets this accomplished easily.

 

This app is planned to be launched in many countries, so it is bound to face issues concerning devices, the network, and various other factors. However, having tested it under predetermined network emulation, we are confident that the app will work efficiently for 700 concurrent users or more.

 

Co-authored by and inputs from Chetan Menaria- Quality Analyst

 

Guest Author Bio: Arup Dey is the Marketing Manager at OpenXcell. Apart from his day to day work, Arup likes to write about App Marketing, Analytics, Testing, and Machine Learning.

You might also find these useful:

Interested in writing for our Blog?Send us a pitch!

Your email is required to complete the test. If you proceed, your test will be aborted.