Share via

  • Article

Capacity Planning

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-12-01

The capacity planning requirements are based on the proposed user models for Office Communications Server 2007 R2. This section describes those user models, and it provides the information to help you do capacity planning for your organization.

User Models

The user models in this section provide the basis for the capacity planning requirements and recommendations described later in this section.

Office Communications Server User Model

The following table describes the user model for Office Communications Server.

Table 1. User Model for Office Communications Server

Category Description

Client distribution

30% of clients running Office Communicator 2007 clients, including Communicator Web Access (2007 release) or Communicator Mobile (2007 release)

70% of clients running Office Communicator 2007 R2, the 2007 R2 version of Communicator Mobile, or Communicator Web Access; 100% of clients running the Live Meeting client

Remote user distribution

90% of users connecting internally

10% of users connecting through an Edge Server, and (recommended) a Director

Contact distribution

Average of 80 contacts on mobile devices

Average of 50 contacts on all other devices

70% of contacts within the organization

10% of enterprise users are remote

10% of contacts are federated

10% of contacts are public IM contacts

IM sessions

2 IM sessions per user per hour

10 instant messages per session

400 byte average message size

Three-person average for multiparty IM sessions

The following table describes the conferencing model used as the basis for capacity planning requirements and recommendations described later in this section.

Table 2. Conferencing Model

Category Description

Scheduled meetings versus "Meet now" meetings

50% of each category.

Meeting concurrency

5% of users will be in conferences during working hours.

Meeting media distribution

15%: PSTN audio through a third-party audio conferencing provider, PowerPoint.

10%: PSTN audio through a third-party audio conferencing provider, application sharing.

15%: Group IM with distribution group integration.

10%: PSTN audio dial-in conferencing only.

10%: VoIP audio, PSTN dial-in conferencing, PowerPoint.

25%: VoIP audio, PSTN dial-in and video, application sharing.

5%: VoIP audio, PSTN dial-in, IM, and application sharing.

10%: VoIP audio, PSTN dial-in, video, IM.

Meeting participant distribution

In meetings where Conferencing Attendant is used with a combination of VoIP audio and PSTN dial-in audio, the ratio of VoIP users to dial-in users is 2:1.

For application sharing, two types of application sharing exist: Persistent Shared Object Model (PSOM) based application sharing using the Web Conferencing Server and Remote Desktop Protocol (RDP) based application sharing based on the new Application Sharing Server. The user model assumes 80% of all ad hoc meetings use RDP-based application sharing and 20% PSOM. For scheduled meetings, the user model assumes that application sharing uses 50% PSOM and 50% RDP.

Assumptions: Meetings with one participant use no RDP application sharing. For scheduled meetings with two participants, the model assumes 20% RDP application sharing. For ad hoc meetings, the model assumes 10% RDP application sharing.

25% remote access.

15% anonymous.

10% federated.

50% internal.

The following table describes the meeting content size model used as the basis for capacity planning requirements and recommendations described later in this section.

Table 3. Meeting Content Size Model

Content type Average size Number of instances

Multimedia Content (Flash, Windows Media player)

50 megabytes (MB)

1

PowerPoint

20 MB

2

Other Microsoft Office Document Imaging (MODI) documents

10 MB

3

Handouts

5 MB

1

Communicator Web Access Model

The Communicator Web Access usage model is based on the Office Communicator usage model, and it includes the following assumptions.

Table 4. Communicator Web Access Usage

Description Value

Total number of users

5,000 plus 120 users doing desktop sharing

Users doing desktop sharing

120 (20 conferences)

Percentage of internal users in contact list

70%

Percentage of legacy users

30%

Average number of contacts per user

50

Maximum number of contacts per user

260

Minimum number of contacts per user

1

Hours logged on per day per user

12

Presence updates per day per user

82

Instant message conversations per day per user

12

Instant message conferences per day per user

1

Instant messages sent per user per conference (peer-to-peer)

10

Instant message sent rate

1 per minute

Instant message sessions per hour

2

Average number of participants in a multiparty session

3

Concurrent conference users at a given point of time

5% of total users

Number of presence queries per user per day

60

User searches per day

12

Contact changes per user per day

13

Percentage of concurrent desktop sharing users

2%

Maximum number of users in a desktop sharing conference

6

Duration of desktop sharing conference

1 hour

The following table lists information about the desktop sharing model.

Table 5. Desktop Sharing Model

Description Value

Users viewing shared desktops

100

Users sharing their desktops

20

Number of conferences

20

Small conference size

2

Medium conference size

3

Large conference size

6

Largest conference size

6

Percentage of small conferences

10

Percentage of medium conferences

15

Percentage of large conferences

70

Percentage of largest conferences

5

Conference duration

1 hours

Conversations per day

24

The usage model in the previous table is based on testing on a Proliant.

Response Group Service User Model

The following table describes the proposed user model for Response Group Service used as the basis for capacity planning requirements and recommendations described later in this section.

This model assumes:

  • The default music-on-hold file is being used.

  • English is being used.

Table 6. Response Group Service User Model

Component Per Enterprise deployment Per Standard Edition server

Active agents (formal and informal)

1,200

1,200

Number of standard Response Groups

450

150

Number of queues used

One unique queue for each hunt group, two for the One-Level Interactive response group

One unique queue for each hunt group, two for the One-Level Interactive response group

Distribution of routing methods on groups

Parallel routing: 40%

Longest idle: 40%

Serial: 10%

Round robin: 10%

Parallel routing: 40%

Longest idle: 40%

Serial: 10%

Round robin: 10%

Percentage of workflows that use speech recognition in their interactive voice response (IVR) versus workflows that use only dual tone multi-frequency (DTMF) in their IVR

Speech recognition/Text-to-speech (SR/TTS) + DTMF: 50% DTMF: 50%

SR/TTS + DTMF:50% DTMF: 50%

Number of hunt groups (mix of 50% simple and 50% complex hunt groups)

600

300

Average number of agents per group

10 agents

10 agents

Average number of groups an agent is a member of

Two groups

Two groups

Number of groups per queue (average)

90%: One group 10%: Two groups

90%: One group 10%: Two groups

Number of simultaneous response group calls

480

60

Average call duration (IVR portion + music on hold)

30 seconds

30 seconds

Average call duration with the agent

3 minutes

3 minutes

Number of sign-in/sign-out cycles for formal agents in a day (based on an 8-hour day)

4

4

Capacity Planning Requirements and Recommendations

The following tables provide information to facilitate capacity planning for your organization.

Table 7. Maximum Supported Users for Each Topology

Topology Servers required Maximum users supported

Standard Edition server

One Standard Edition server

5,000

Enterprise pool, consolidated configuration

Eight Enterprise Edition Front-End Servers running all server roles

One Back-end SQL Server

100,000

Note

If deploying only IM and presence, Office Communications Server 2007 R2 supports 200,000 client end points, where each end point is a client program, such as Communicator, based on eight Front End Servers and a 16-core computer running the Microsoft SQL Server database software. The back-end database must run on a 4-way processor, quad core, or 8-way, dual core, 2.0 GHz+ computer.

Archiving Server

One Archiving Server

300,000

Monitoring Server

One Monitoring Server

200,000

Group Chat Server

Three Group Chat Servers

60,000 (20,000 per server).

Note

You must deploy QFE 1 for this increased server and user support.

Edge Server topologies assume 10% of the total user base will be connected from outside the intranet. The following table shows the maximum number of client connections supported by each of the following Edge Server roles and topologies.

Table 8. Maximum Supported Clients for Edge Server Topologies

Topology Supported performance

Edge Server

Access Edge service: 5,000 client connections

Web Conferencing Edge service: 1,000 client connections

A/V Edge service: 500 concurrent audio/video (A/V) sessions

Deployment of a Director is recommended for external access.

Table 9. Communicator Web Access Capacity

Performance metric Communicator Web Access presence and IM, Communicator Mobile for Java, search, and desktop sharing

Number of users

5,000 users

120 concurrent desktop sharing users

Note

Computer configuration: 2.3 GHz CPU, 8.0 GB memory, 8 processors, Kernel SSL disabled, ASP NET 1.5 request queue limit of 1.5 * the number of concurrent users of the server, HTTPS connection, no collocation with other virtual server or Office Communications Server, 16 GB virtual memory, Communicator Web Access logging (retail tracing) set to off

Note

Computer configuration: 3.0 GHz CPU, 1.0 GB memory, 100 Mbps network, 80 GB hard drive, Internet Explorer 7.0 browser, Microsoft Windows XP SP2 operating system, 1280x1024 display

Table 10. Storage Disk Capacity Planning

Storage drive Average disk bytes per read and average disk bytes per write (for 100,000 users) Disk reads and writes (per second, for 100,000 users)

Enterprise pool backend data drive

Read: 0

Write: 2,180

Read: 0

Write: 158.3

Enterprise pool RTC log

Read: 0

Write: 832

Read: 0

Write: 216.2

Enterprise pool RTCdyn log

Read: 996

Write: 2,289

Read: 0.002

Write: 561.3

Archiving log file drive

Read: 0

Write: 3,783

Read: 0

Write: 110.1

Archiving data file drive

Read: 761

Write: 3,532

Read: 0.091

Write: 38.7

Monitoring (QoE and CDR) data log drive

Read: 8,192

Write: 6,213

Read: 85.5

Write: 193.1

Table 11. Archiving and Monitoring Database Storage Capacity Planning

Component Average growth of database per hour Usage assumptions

Archiving database

636 MB per hour per 100,000 endpoints

Based on 320 messages per second, 400 bytes per message

Monitoring database

CDR: 162 MB per hour for 100,000 endpoints

QoE: 482 MB per hour for 100,000 endpoints

Assumes that clients do not create QoE data for video calls

Table 12. Group Chat Capacity Planning

Chat room usage User connection rate Message rate

Each user participates in 30 chat rooms

Each chat room has 30 participants

Two user connections initiated per second, per server

40 messages per second (all chat rooms)

Note

Chat rooms can support more than 30 participants, and the Group Chat client is capable of supporting more than 30 chat rooms. However, large numbers of participants in a chat room may impact server performance. The maximum tested configuration for chat rooms is 1,000 participants. Use of chat rooms with large numbers of participants should be limited to no more than 10% of all chat rooms created.

Note

Updated Group Chat capacity planning documentation, as well as a capacity planning spreadsheet, is available as a free download from the Microsoft Download Center:

Table 13. Application Sharing Capacity Planning for Persistent Shared Object Model (PSOM) Applications

Application sharing usage Sent and received (KBps) Processor time Average bandwidth usage per user (Kbps)

15 conferences, 90 users

Received: 1,370 (2,728 peak)

Sent: 6,370 (12,315 peak)

Average: 8.5

Peak: 24.4

Sent per sharer: 713.57

Received per viewer: 552.92

Table 14. Mediation Server Capacity Planning

Computer

90% internal users , 10% external/remote users

Dual processor, dual core, 3.0 GHz CPU, with 4 GB memory and 2 x 1 Gbps network adapter card

Dual processor, quad core, 2.3 GHz CPU, with 4 GB memory and 2 x 1 Gbps network adapter card

100% external/remote users

Dual processor, dual core, 3.0 GHz CPU, with 4 GB memory and 2 x 1 GB network adapter card

Dual processor, quad core, 2.3 GHz CPU, with 4 GB memory and 2 x 1 GB network adapter card

Note

In the preceding table, CPU utilization is assumed to be 75% of capacity.
Scaling numbers for Mediation Server depend on the location of the users, primarily how far the user is from the Mediation Server. For users outside the internal network, the media stack uses a lower bit rate, which can significantly impact performance.

Capacity planning for Address Book Server requires that you plan for the size of the Address Book Server database and Address Book Web query service database, the size of the download files, and the number of Office Communicator Mobile for Windows clients that will access the Address Book Web query service.

The size of the disk used for the Address Book Server database and the file server where Address Book Server creates download files depends largely on the number of contacts that must be stored. (The file server can be used to store other data as well. For details, see the “Folders” section in Storage Requirements.) One way that you can estimate the number of contacts that Address Book Server will store in the database and in the download files is to assume that each user has two Contact objects. As a result, you can estimate storage requirements for Address Book Server by multiplying the number of users in your organization by two.

  • General Address Book download file size assumptions:

    • 100,000 contacts, 2.5 GB storage for download files (based on two contacts per employee)

    • 100,000 employees, 5 GB storage for download files

  • General Address Book Web Query database size assumptions:

    • 100,000 contacts, 1.5 GB storage

    • 1 GB for database log

Table 15. Address Book Web Query Service Performance for an Enterprise Pool

Number of users Maximum number of mobile devices Number of entries in Address Book database Queries per second Usage notes

Total: 100,000

Voice-enabled: 30,000

18,000 (60% of Voice-enabled users)

300,000

Average: 17.7

Peak hours: 26.55

Eight Front End Servers

30% of users are enabled for unified communications.

100 queries per second has a minimal impact on performance.

Table 16. Audio/Video Capacity Planning

Media Codec Average bandwidth (Kbps) Estimated activity (%) Maximum bandwidth (Kbps)

Wideband Audio

RTAudio

34.8

61

57

Wideband Audio

Siren

22.2

43

51.6

Narrowband Audio

RTAudio

25.9

65

39.8

Video

RTVideo

258.3

82

350

Panoramic Video

RTVideo

220.5

70

350

  • Bandwidth numbers quoted for media streams include all overhead for framing, encryption, and IP routing information in addition to actual encoded media.

  • Average codec bandwidth values are based on measurements and derived from the maximum theoretical bandwidth based on typical activity level values. Audio activity levels take into account voice activity in the stream. Video activity levels take into account the amount of motion within the video images.

  • Activity levels for RT Audio Narrowband is slightly higher to allow for less optimal Voice Activity Detection in PSTN Gateways for Office Communications Server VoIP-to-PSTN calls. This number should be increased by another 15% if no Voice Activity Detection is enabled on the deployed PSTN Gateway.

  • Activity level of Panoramic Video is lower than for regular video streams because there is a higher relative proportion of background area within panoramic images.

Media Bandwidth Requirements and Recommendations

For basic media gateways, the bandwidth requirement between gateway and Mediation Server is 80 Kbps for each concurrent call. Multiplying this number by the number of ports for each gateway is a fair estimate of the required bandwidth on the gateway side of the Mediation Server. On the Office Communications Server side, the bandwidth requirement is considerably lower.

When configuring Mediation Server, you should accept the default media port gateway range of 60,000 to 64,000. Reducing the port range greatly reduces server capacity and should be undertaken only for specific reasons by an administrator who is knowledgeable about media port requirements and scenarios. For this reason, altering the default port range is not recommended.

High-bandwidth traffic such as voice and video tends to stress networks that are not appropriately provisioned. Limiting media traffic to a known range of ports makes troubleshooting such problems easier.

Mobile Data Bandwidth Requirements

Approximately 1 MB of bandwidth is required for mobile access for an 8-hour work day. This is based on the following usage:

  • One distribution group, with 15 users

  • 80 members in contacts list, with four presence updates per user per hour

  • One tagged contact with four presence updates in one hour

  • 12 phone calls per day, with 1 phone call per hour (1 incoming and 1 outgoing every two hours)

  • Two minutes per call

  • User is logged into one additional end point (such as Office Communicator or a desk phone)

  • One IM session every two hours

  • Outgoing and ingoing IMs are equal (1:1)