Size Your Mobile Backend on IBM Cloud Using Mobile Foundation

Share this post:

Sizing the initial baseline of Mobile Foundation app instances

Mobile Foundation offers a comprehensive mobile backend that includes a secure Mobile API gateway, App Insights, Push, Feature toggle, and more for web and mobile applications. Developers can pick a language and a framework of choice—React Native, Swift, Java for Android, or JS—to build a secure, rich, and scalable app. The Mobile Foundation service hides all the integration complexity, allowing developers to focus on building their apps.

During Mobile Foundation Service instance creation, developers often find it difficult to size the number of Cloud Foundry (CF) instances (the first step in setting up the Mobile Foundation Service Dashboard for professional plans). Optimally sizing the initial baseline of Mobile Foundation app instances to handle incoming requests from mobile apps is critical for proper functioning of the app. This post offers a quick summary for developers to determine the baseline number.

Mobile apps tend to exhibit high variability; hence, developers often find it difficult to size the mobile backend for their app. Integration architectures also differ from one deployment to the other. Understanding the nuances of an app and sizing the backend appropriately ensures proper utilisation of the infrastructure. This post offers a quick back-of-the-envelope sizing calculation so developers can set up an enterprise-grade backend for their app. Developers can then set up auto-scale policies to scale-out or scale-in their mobile backends.

Mobile Foundation service deploys a CF-Mobile Foundation cluster in the org and space of the user (mounting the appropriate libraries), which is tethered to the service instance. The service instance manages the life cycle of these CF-Mobile Foundation instances so developers don’t need to worry about their inner-workings. However, the developer can perform various other functions on this app using Cloud Foundry utilities offered in the IBM Cloud dashboard. For example, developers can set up monitoring services and monitor the availability of the route from various IBM Cloud pods using the Availability Monitoring add-on. Developers can also configure Logs and view the instance logs in Kibana.

Throughput (TPS)

1. Calculating transactions: The ‘T’ in TPS (HTTP Calls)

There are few aspects to keep in mind:

  • Start with the total number of users using your app (N): Depending upon whether your app is a B2C (consumer facing) app or a B2E (employee facing) app, arrive at an approximate number. For example, a B2E app for a mid-size 20,000-member company might have 40,000 app downloads (assuming more than one device per user).
  • Percentage of users at peak load (P): Remember, you are planning to offer the best experience at peak load. Auto-scale is certainly a strategy to adopt, but planning for a peak will ensure that sufficient capacity is in place to get started.
  • Total duration a user would be active (D): User opens up an app, logs in, checks some status, and once done, closes the app. D is the total duration of the app being used.
  • Think time or Interval between clicks (I): User takes few seconds to read what is on the screen before clicking the next action. This is the time interval between two such clicks. This duration also helps in computing concurrency.
  • Adapter calls per click (A): A user click is associated with a certain number of HTTP calls to a Mobile Foundation instance. Note that the Mobile Foundation service is a stateless backend; there is no session aspect while responding to these HTTP calls.

The above set of parameters will help you calculate the total number of HTTP calls.

Total Network Calls = N*P*(D/I)*A

Let’s take the example of a mobile banking app:

  • N = 40,000 (40k users)
  • P = .2 (20% peak users)
  • D = 300 (5mts duration)
  • I = 5s (5s think time)
  • A = 3 (average number of Adapter/HTTP calls per click sent to cf instance)

The total number of network calls (T) at peak load (P) will be:

T = 40,000*0.2 * (300/5) * 3

Total Transactions = 1.44M HTTP Calls

2. Calculating duration: The ‘S’ in TPS

The next step is to find how long (L) the peak load lasts. For example, at the beginning of the day, your peak load (20%) users log into the app to perform certain functions. This could be all employees logging in to clock-in for that day.

Therefore, if the peak load lasts for one full hour:

L = 60 mts*60 sec = 3600 seconds

Now that we have both number of transactions (T) and the duration of peak load we can arrive at throughput:

T/L = 1.44M/3600 = 400 TPS

At peak load, your mobile backend will need to serve 400 transactions per second.

Now that we have TPS for the backend, think time (I), and an average number of network calls (A), we can also estimate how many concurrent users (U) this mobile backend can serve.

Concurrent Users (U) at Peak = (TPS/A) * I = (400/3)*5 = 667 Users

3. Calculating TPS when active users (concurrent users) at peak is known

Many organisations know their peak concurrent (Active) users number. They can simply calculate the required TPS using this formula:

TPS for known active users = Concurrent Users at Peak (U) * (A/I)

In our case, it should yield 400 TPS for 667 Users.

TPS for 667 Active Users = 667 * (3/5) = 400 TPS

4. Number of CF instances (T-shirt size)

A typical Mobile Foundation Cloud Foundry node can handle approximately 200-250 TPS per 2G instance. Therefore, for the above configuration, we will need:

Total CF-MF Instances required = TPS/CF-instance capacity  = 400/200 ~ 2 instance of 2G

A developer has to allocate two Cloud Foundry instances of 2G each to serve 40,000 users at one-hour peak load. During Mobile Foundation Service instance creation (Per Device or Per Application plans), this number should be set in the Mobile Foundation Service Dashboard. The Developer plan defaults to a single instance. In case you arrive at a TPS that yields less than two instances, we recommend using at least two instances for a highly-available topology. In a multi-zone region (MZR) such as US-South, IBM Cloud will guarantees placement of pods in separate zones, thus offering higher availability.

Please note that the above is a guidance blog. The sizing could vary significantly depending on the type of the app. A highly interactive app might end up making a lot more networking calls, meaning a developer will need to allocate more memory per instance while increasing the number of instances.

Join the conversation to discuss this and other Mobile Foundation Service topics in our dedicated Slack channel.

Architect - IBM Mobile

Girish Dhanakshirur

IBM Distinguished Engineer - IBM Cloud Mobile

Amit Goyal

Architect - MobileFirst & Enterprise Mobile Apps

More Mobile stories