Capacity Planning for Mobility
Topic Last Modified: 2011-12-05
Determining the amount of capacity that you need for mobility is an iterative process of estimating your mobility usage, measuring your current capacity, planning for additional capacity, and monitoring key indicators for performance. The following figure illustrates the phases involved in capacity planning and the factors involved in each phase.
Mobility Capacity Planning Workflow
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
This section describes the factors you need to consider as you estimate your mobility usage and provides guidelines for determining the sizing you need to deploy mobility.
For details about monitoring usage and performance indicators, see the following:
For details about monitoring server memory, see Monitoring for Server Memory Capacity Limits.
For details about monitoring mobility usage, see Monitoring Mobility Service Usage.
For details about monitoring IIS tracing log files, see Monitoring IIS Request Tracing Log Files.
For details about performance counters you can use to monitor mobility, see Mobility Performance Counters.
For details about configuring Mobility Service for high performance, see Configuring Mobility Service for High Performance.
Factors Influencing Capacity
Three factors influence your capacity planning for Front End Servers running the Microsoft Lync Server 2010 Mobility Service:
User model
Mobile device characteristics
Available RAM
User Model
The user model described in this section provides the basis for the capacity planning measurements and recommendations for mobility.
Average Number of Contacts per User
| Category of contacts | Average number per user |
|---|---|
All contacts |
80 |
Enterprise contacts |
64 |
Federated contacts |
8 |
PIC contacts |
6 |
Distribution groups |
2 |
Most frequently used contacts |
15 |
Most recently used contacts |
10 |
Daily Activity per User
| Daily activity | Number during working hours | Number outside working hours |
|---|---|---|
Sign-ins to mobile application |
10 |
2 |
Phone calls (number) |
10 |
2 |
Phone calls (duration) |
2 minutes per call |
2 minutes per call |
Conferences |
1 per week |
0 |
Participants per conference |
<10 |
0 |
Status note changes |
1 |
0 |
Views of contact card |
6 |
1 |
Views of Contacts list |
9 |
1 |
Scrolls through Contacts list |
3 |
0 |
Global address list (GAL) searches |
5* |
- |
Manual presence updates |
0.5 |
0 |
Total presence updates per contact |
6 |
0 |
Call forwarding |
0.5 |
0 |
Instant messaging (IM) sessions (number) |
3 |
1 |
IM sessions (duration) |
6 minutes per session; 1 message per 30 seconds |
6 minutes per session; 1 message per 30 seconds |
Calendar lookups (connections to Exchange Web Services) |
11 |
3 |
* Number of GAL searches = 1 manual search per day + automatic searches on half of outgoing instant messages and calls. That is, 1 + 2 (instant messages) + 2 (calls) =5.
Mobile Device Characteristics
The mobile devices supported for mobility run a variety of operating systems. The way in which an operating system manages applications when a user switches to a different application influences capacity planning. Operating systems can be divided into the following two categories for capacity planning:
Background enabled When a user switches to a different mobile application on Apple and Windows Phone mobile devices, the Lync 2010 mobile application goes to the background and loses the connection to Lync Server 2010. The mobile application is reactivated by a push notification or when the user manually brings the application to the foreground.
Always connected When a user switches to a different mobile application on Android and Nokia mobile devices, the Lync 2010 mobile application maintains the connection to Lync Server 2010 as long as the user stays signed in.
Android and Nokia mobile devices create a bigger load on servers because they maintain the connection to the server even when the user is not actively using the mobile application.
Available Memory
The sizing guidelines described later in this section will help you define the amount of memory you need for mobility. To determine the amount of physical memory that is available on your servers, use the Memory, Available Mbytes performance counter. This performance counter indicates the amount of physical memory in megabytes that is available for running processes. If the amount of memory available for running processes is less than five percent (5%) of the total physical memory, the server has insufficient memory, which can increase paging.
Sizing Guidelines
The Mobility Service uses additional memory, processor resources, and network resources on Front End Servers. When you plan for capacity, you need to understand the impact of the mobility load on the Front End pool and decide whether you need additional hardware for the mobility load. Use the sizing examples in the table that follows to help determine whether, and how much, additional hardware you need.
The examples in the table are based on some formulas and assumptions. The formulas and assumptions use the following definitions:
AC stands for the number of mobile applications that are always connected in the user model.
BE stands for the number of mobile applications that are enabled for the background in the user model.
The formulas and assumptions are as follows:
Target memory (TM) in Mbytes = 164 + (AC * 534 + BE * 400) / 1024.
TM is the minimum required memory.
With the user model described previously, the number of connections to the Front End pool is AC * 2 + BE * .20.
Measured memory may be higher (up to 1 MB per endpoint) when there is no memory pressure on the server. Target memory can be higher if your user model is more aggressive, such as when there are more audio/video (A/V) calls or contacts, and so forth.
The number of connections created per second is less than or equal to 30/second per 1,000 users. This number depends on connection pooling settings on the hardware load balancer and on keep-alive settings.
The following table shows examples of sizing for 50% always-connected users in the user model.
Sizing Examples
| Number of users | Memory (MB) | Average CPU | Maximum CPU |
|---|---|---|---|
1,000 |
620.05 |
1% |
2.5% |
2,000 |
1076.11 |
6% |
8% |
3,000 |
1532.16 |
14% |
18% |
4,000 |
1988.22 |
14% |
18% |
5,000 |
2444.27 |
14% |
18% |
Scenario Examples
The following examples show how the sizing guidelines apply to a fictional large enterprise and a Front End pool that includes two servers.
Large enterprise
Contoso has deployed 75,000 users across three pools with four Front End Servers in each pool. Contoso plans to enable mobility services to 30,000 users.
During the planning phase, Contoso administrators capture the following data:
Each Front End Server has 3 GB of available memory.
CPU utilization is less than 60%.
All users have either an iPhone or a Windows Phone mobile device.
The user model for Contoso is similar to the capacity planning user model described earlier in this section.
The minimum required memory for each server is 164 + 2500 * 400 / 1024 = 1133 MB. When there is memory available, more memory may be allocated to the mobile applications because memory is freed up as needed, up to 2.7 GB. In either situation, Contoso does not need to upgrade the Front End Server hardware.
Note
The goal for mobility CPU utilization is an average of 10%. Contoso needs to monitor the CPU processor time as it gets close to the server limit of 70%.
Front End pool with two servers
Contoso has deployed 8,000 users in a Front End pool with two servers. Contoso plans to enable mobility services to all users.
During the planning phase, Contoso administrators capture the following data:
Each Front End Server has 2.5 GB of available memory.
CPU utilization is less than 60%.
All users have either a Nokia or an Android mobile device.
The user model for Contoso is similar to the capacity planning user model described earlier in this section.
The minimum required memory for each server is 164 + 4000 * 534 / 1024 = 2242 MB. In theory a server could support the load. However, a server will not support the load if a failover occurs between the two servers. Additionally, the mobility CPU utilization will be above 10% and the server 70% CPU limit will be reached.
In this scenario, the recommendation is to add a server to the pool. The new load distribution is 2667 (that is, 8000/3) users per Front End Server. The additional mobility cost is 2667 * 534 / 1024 = 1390 MB.
With the addition of a server, in the event of a server failure, each of the three servers in the pool will accept 1,300 more users and the increase in load will be 600 MB. With the new load distribution, the CPU utilization will also remain below the 70% server limit.