Engineering

Orchestrating Better In-App Chat Experiences for 100K Concurrent Users!

Published On July 21st, 2022 Engineering

As diligent enablers of proficient in-app communication experiences, committing to deliver high performance at scale has always been our forethought; this meant that our product teams must go all out in developing bug-free and superior in-app solutions across all platforms and niches.

Discerning the criticality of these API & SDK-led implementations, CONTUS MirrorFly engineereda pipeline of thorough load testing measures to validate and surpass user expectations with ease, time and again.

Here’s presenting the detailed walkthrough of our recent test endeavor, where we happened to cross off some of the top priority metrics: 100k concurrent users, performance, memory utilization and more

The Case of Load Testing, an Overview:

Given the power to jumpstart word-class in-app communication experiences, our prime objective behind this procedure was to assess and improve the load bearing capacity of MirrorFly’s microservices API, sockets and XMPP services, used extensively for such messaging incidents. 

By evaluating the structural complexities, use cases and other dependencies, our internal team fixated on certain key considerations to improve the scalability, performance and sustainability of the deployed chat API services.

Key Considerations:

The aforementioned experimentation strategy intended to substantiate these key objectives 

  1. Need to handle 100k concurrent users 
  2. Assess the endurance of the server and ensure to record the concurrent user capacity up until a completed chat transaction
  3. Response time should be less than 5% and error rate less than 1%

Putting Scalability and Performance to Test:

In MirrorFly, an end user’s communication journey encompasses instant messaging experiences primarily fulfilled by API and XMPPs in the first place. 

In pursuit of evaluating the competence and architectural integrity of these services under varied load constraints, our core test process relied on applying the mentioned stress parallelly on either of these services for well-structured chat and media-file observations.

We had relied on Tsung, the distributed load-testing tool to test the scalability and efficiency of server based applications accurately.

Likewise, for emulating an ideal test environment, average page requests per second(between 400 and 500 seconds) and user time(8 minutes) were identified to be the test variables and conditions for achieving efficacy.

Now, before delving deep into the experimentation insights, outlining a little background on either of these test scenarios, tools and criterion involved for deeper understanding.

Testing APIs as a Whole:

Primarily, an API-enabled messaging interface permits users to connect with each other via media file sharing capability, call log data and contact directory access.

Traversing this user journey in our platform, Apache Jmeter tool was put to use in order to create the depicted environment and gauge the said service with the below load criterion:

  • Concurrent users – upto 100k users
  • Ramp up rate – 71 users every second 

Testing XMPPs as a Whole:

Conventionally, a XMPP service warrants users the competence to get started by authentication and start conversing with peers via instant messaging. 

Over here, we had utilized the Tsung tool to emulate this process flow and to assess the service fit with precision via following load criterion

  • Concurrent users – upto 100k users
  • Ramp up rate – 200 users every second 

Key Findings: 

Upon meticulous execution of these stress assessments, we were able to plot down the key metrics, and obviously, most of these insights leave a positive impact on our current in-app offerings with room for improvement in few areas.

Let’s explore these nuanced results in detail:

  • The server can handle 100k users with a total of 19.6 CPU and 41.5 GB RAM (inclusive of MySQL, XMPP, API services), with an average usage of 30% CPU and 50% Ram can be handled.

MYSQL Memory Usage:

MYSQL Memery Usage

 MYSQL CPU Usage:

MYSQL CPU Utilization

  • Intended peak load is achieved with less than 50% memory utilization 

Kubernetes CPU Usage:

kubernetes CPU Usage

Kubernetes Memory Usage:

Kubernetes Memory Usage

  • Apdex score is fair for 100k users
  • Resource utilization in the event of login and media entities seem to be higher however no errors are recorded on it

Scaling Growth and Innovation with Testing: 

‘How do we make in-app communication better across all our apps?’

Driven by this growth-oriented mindset, we at CONTUS MirrorFly are constantly pushing ourselves towards offering the best in-app communication experiences for our users via API and XMPP services.

Ergo, deciphering this recent testing attempt has helped us postulate our major wins and through more such measures in the pipeline, we aim to continually improve our service offerings to foster highly-responsive, error-free in-app development over and over again. 

Blog CTA

Sadhana

Sadhana is an avid reader and passionate writer who loves to pen down her thoughts on all things tech and new-age communication. Being a new-gen millennial herself, she loves creating mature, precise content that transcends better across the board.

As diligent enablers of proficient in-app communication experiences, committing to deliver high performance at scale has always been our forethought; this meant that our product teams must go all out in developing bug-free and superior in-app solutions across all platforms and niches.

Discerning the criticality of these API & SDK-led implementations, CONTUS MirrorFly engineereda pipeline of thorough load testing measures to validate and surpass user expectations with ease, time and again.

Here’s presenting the detailed walkthrough of our recent test endeavor, where we happened to cross off some of the top priority metrics: 100k concurrent users, performance, memory utilization and more

The Case of Load Testing, an Overview:

Given the power to jumpstart word-class in-app communication experiences, our prime objective behind this procedure was to assess and improve the load bearing capacity of MirrorFly’s microservices API, sockets and XMPP services, used extensively for such messaging incidents. 

By evaluating the structural complexities, use cases and other dependencies, our internal team fixated on certain key considerations to improve the scalability, performance and sustainability of the deployed chat API services.

Key Considerations:

The aforementioned experimentation strategy intended to substantiate these key objectives 

  1. Need to handle 100k concurrent users 
  2. Assess the endurance of the server and ensure to record the concurrent user capacity up until a completed chat transaction
  3. Response time should be less than 5% and error rate less than 1%

Putting Scalability and Performance to Test:

In MirrorFly, an end user’s communication journey encompasses instant messaging experiences primarily fulfilled by API and XMPPs in the first place. 

In pursuit of evaluating the competence and architectural integrity of these services under varied load constraints, our core test process relied on applying the mentioned stress parallelly on either of these services for well-structured chat and media-file observations.

We had relied on Tsung, the distributed load-testing tool to test the scalability and efficiency of server based applications accurately.

Likewise, for emulating an ideal test environment, average page requests per second(between 400 and 500 seconds) and user time(8 minutes) were identified to be the test variables and conditions for achieving efficacy.

Now, before delving deep into the experimentation insights, outlining a little background on either of these test scenarios, tools and criterion involved for deeper understanding.

Testing APIs as a Whole:

Primarily, an API-enabled messaging interface permits users to connect with each other via media file sharing capability, call log data and contact directory access.

Traversing this user journey in our platform, Apache Jmeter tool was put to use in order to create the depicted environment and gauge the said service with the below load criterion:

  • Concurrent users – upto 100k users
  • Ramp up rate – 71 users every second 

Testing XMPPs as a Whole:

Conventionally, a XMPP service warrants users the competence to get started by authentication and start conversing with peers via instant messaging. 

Over here, we had utilized the Tsung tool to emulate this process flow and to assess the service fit with precision via following load criterion

  • Concurrent users – upto 100k users
  • Ramp up rate – 200 users every second 

Key Findings: 

Upon meticulous execution of these stress assessments, we were able to plot down the key metrics, and obviously, most of these insights leave a positive impact on our current in-app offerings with room for improvement in few areas.

Let’s explore these nuanced results in detail:

  • The server can handle 100k users with a total of 19.6 CPU and 41.5 GB RAM (inclusive of MySQL, XMPP, API services), with an average usage of 30% CPU and 50% Ram can be handled.

MYSQL Memory Usage:

MYSQL Memery Usage

 MYSQL CPU Usage:

MYSQL CPU Utilization

  • Intended peak load is achieved with less than 50% memory utilization 

Kubernetes CPU Usage:

kubernetes CPU Usage

Kubernetes Memory Usage:

Kubernetes Memory Usage

  • Apdex score is fair for 100k users
  • Resource utilization in the event of login and media entities seem to be higher however no errors are recorded on it

Scaling Growth and Innovation with Testing: 

‘How do we make in-app communication better across all our apps?’

Driven by this growth-oriented mindset, we at CONTUS MirrorFly are constantly pushing ourselves towards offering the best in-app communication experiences for our users via API and XMPP services.

Ergo, deciphering this recent testing attempt has helped us postulate our major wins and through more such measures in the pipeline, we aim to continually improve our service offerings to foster highly-responsive, error-free in-app development over and over again. 

Blog CTA

Sadhana

Sadhana is an avid reader and passionate writer who loves to pen down her thoughts on all things tech and new-age communication. Being a new-gen millennial herself, she loves creating mature, precise content that transcends better across the board.

Leave a Reply

Your email address will not be published.