Load Testing a Real Estate App With BlazeMeter

DZone 's Guide to

Load Testing a Real Estate App With BlazeMeter

Follow along as we see how to perform load testing a real estate app with BlazeMeter.

· Performance Zone ·
Free Resource

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.

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 web services 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

concurrent, response time, testing, ui, web

Published at DZone with permission of Arup Dey , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}