Deploying MobileFabric in your Environment: Part II – Sizing
Ajay Bhat - May 27, 2016 - Engineering
This post is Part II of a multi-part series focusing on deploying MobileFabric in your On Premise environment. In this series, Pattabhi Dasari and I will provide details on how to plan out your MobileFabric deployment, and share best practices. Part I, which details software requirements and deployment topologies is here.
Sizing
A common request that we get from customers is for a sizing guide to help them decide on the optimal deployment configurations for their particular app and user requirements. This guide is an attempt to capture requirements from different MobileFabric components in a single place.
The table below illustrates the sizing for each MF component. Reporting agent will be installed for analytics and is required.
Note – 1 CPU and 2 GB will be allocated for the OS on each physical box. Please note that Reporting Agent should be installed along with Integration on the same physical box.
Sample Illustrations
- A customer needs MobileFabric Integration for handling 1.25 million sessions/year, Engagement for 80 pushes/sec and Sync for 120 concurrent user/sec. For high availability, an additional physical box will be added:
- A customer needs MobileFabric Integration for handling 2 million sessions/year, Engagement for 80 pushes/sec and Sync for 300 concurrent user/sec.
- Customer needs MobileFabric Integration, Identity, Engagement & Reporting for handling 1.2 million sessions/year on Azure Linux cloud with SQL Server.
As an illustration, each ‘Standard tier: Dv2-series – Standard_D3_v2’ server can handle 1.25 million sessions per year. Two ‘Standard tier: Dv2-series – Standard_D3_v2’ server need to be configured for high availability so that the environment can handle any spikes and serves up to 2 million sessions per year. For every additional 1.25 million session /year, you will need additional ‘Standard tier: Dv2-series – Standard_D3_v2’ server.
If high availability is required for MobileFabric Console & Reporting portal, then 2 ‘Standard tier: A-series – Standard_A2’ servers will be required.
We’ve included a similar illustration using AWS using EC2 and RDS for MySQL below as an example.
For Production
For Dev / QA Environments
Note: If separation of concern and high availability of particular runtime is important then the runtimes should be configured on different physical nodes.
For more information on VM sizes and other performance aspects, please refer to the following links: