• Article

Appendix B: Planning for Capacity Requirements

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.

This appendix discusses the factors that affect the number of concurrent users that can be supported on a Microsoft® Office Communicator Web Access (2007 release) server. It also presents the results of capacity tests that have been performed on various hardware and software configurations. This information is intended to help administrators plan a Communicator Web Access deployment that meets current and future capacity needs.

When running Communicator Web Access (2007 release) on a server, the following factors affect user capacity:

  • Usage model

  • Server RAM

  • /3 GB switch on the Microsoft Windows Server® operating system

  • Kernel SSL switch

  • Communicator Web Access connection type

  • ASP.NET requestQueueLimit setting

This appendix briefly describes these factors and presents the results of capacity testing on various combinations of these factors. You can use the test results to estimate the capacity of your Communicator Web Access servers and determine whether adjusting certain settings will increase user capacity on your servers.

Baseline Communicator Web Access Configuration

The capacity testing conducted for this appendix used a baseline hardware and software configuration and usage model. The maximum number of concurrent users that could be sustained in this environment was tested, and then various adjustments to the baseline environment were tested to determine the effects on capacity.

This section describes the baseline hardware and software configuration and usage model that were used in the capacity testing scenarios. The baseline configuration is based on the recommended minimum requirements for the Communicator Web Access server.

Baseline Configuration

For this appendix, Capacity was tested on a server that met the standard Communicator Web Access (2007 release) hardware requirements outlined in Table 1. The standard software configuration outlined in Table B-1 was used as the baseline for capacity testing purposes.

Table B-1. Baseline Communicator Web Access (2007 release) Server Configuration

Physical Configuration  

RAM

4 GB

CPU

3.0 GHz dual processors (Hyperthreading enabled)

Network bandwidth

100 megabit

Load balancer offloading SSL

No

Software Configuration

 

/3G switch

Off

Kernel SSL

Off

requestQueueLimit for ASP.NET

8000 (you must change the default to 8000)

Communicator Web Access connection type

HTTPS

Collocation with other virtual server

No

Collocation with Office Communications Server

No (Not supported)

Virtual memory size

8 GB

Communicator Web Access logging (retail tracing)

Off

Usage Model

The Communicator Web Access usage model is based on the Office communicator 2007 usage model, and includes the following assumptions:

  • All users are simultaneously active and logged on. This is a conservative estimate that approximates the highest impact scenario.

  • Users have an average of 50 contacts in their Contacts list and an equal number of users watching their presence.

  • Users are logged on to a single device.

  • Each user participates in two IM sessions per hour.

  • The duration of each IM session is 5 minutes.

Table B-2 lists capacity performance numbers for a Communicator Web Access Server deployment with this usage.

Table B-2: Performance Metrics

Criteria Minimum

Number of endpoints per server

4250

Percentage of internal users in contact list

70%

Percentage of legacy users

15%

Percentage of Federated users

15%

Average number of contacts per user

50

Hours logged on per user per day

12

Presence updates per user per day

82

IM conversations per user per day

24

Number of messages per session

10

Sign-ins in 12 hours

2

IM sessions per hour

2

Number of INFOs per session (is-typing)

10

Average Number of participants in a multiparty session

3

Number of presence queries per user per day

30

User searches per day

31

Contact changes per user per day

13

Factors Affecting Communicator Web Access Capacity

A number of hardware and software factors can be adjusted to help increase the maximum number of concurrent users that a Communicator Web Access server can support. This section describes the hardware and software factors that we studied and discusses their impact on capacity.

Hardware Factors

We studied the effect of changing CPU speed, network bandwidth, and available RAM on system capacity. Changing the CPU speed and network bandwidth did not appear to have a significant impact on Communicator Web Access capacity. Of the three hardware factors, Increasing RAM had the greatest impact on the capacity of the server.

Software Factors

The following software factors affect Communicator Web Access server capacity. These factors and settings were adjusted during capacity testing to determine their impact on the maximum number of users that a server could support.

  • Windows Server /3GB Switch

  • Kernel SSL switch

  • ASP.NET requestQueueLimit

  • Communicator Web Access (2007 release) server connection type

  • Collocating Communicator Web Access (2007 release) and Office Communications Server 2007

The following sections describe each of these software factors and how they affect Communicator Web Access capacity.

Windows Server 2003 /3GB Switch

By default, Windows Server 2003 allocates 2 GB of virtual memory to the system kernel and 2 GB to user-mode processes. You can, however, cause the operating system to allocate 3 GB of virtual memory to user-mode processes and 1 GB to the kernel by setting the /3GB switch on that server. Setting the /3GB switch increased the capacity of the Communicator Web Access server.

To set the /3GB switch in Windows Server 2003

  1. Right-click My Computer, and then click Properties.

  2. In the System Properties dialog box, click the Advanced tab.

  3. In the Startup and Recovery area, click Settings.

  4. In the Startup and Recovery dialog box, in the System startup area, click Edit. This action opens the Boot.ini file in Notepad.

  5. In the [Operating Systems] section, at the end of the startup line that includes the /fastdetect switch, type /3GB.

  6. Save the changes, and then close Notepad.

  7. Click OK two times to close the dialog boxes, and then restart the computer for the change to take effect.

For more information about the /3GB option, see the following articles:

Kernel SSL switch

Windows Server 2003 SP1 or later provides the option of running SSL (Secure Sockets Layer) in kernel mode. User mode SSL is the default. The kernel mode feature improves SSL performance by moving encryption and decryption operations to the kernel, thereby reducing the number of transitions between kernel mode and user mode. The kernel mode also reduces the memory consumption of server-side processes so that more memory is available to Communicator Web Access. Although moving encryption and decryption operations to the kernel can increase CPU usage, for Communicator Web Access the benefits of additional memory outweigh any disadvantages associated with higher CPU usage. Enabling kernel mode SSL disables user mode SSL and requires the HTTP service to be restarted to take effect. Kernel mode SSL is controlled by the EnableKernelSSL registry value.

To enable kernel SSL

  1. Open Registry Editor.

  2. Go to the following registry key:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

  3. Create a new value named EnableKernelSSL in this location, set the type to REG_DWORD, and set the data value to 1.

  4. Restart the HTTP service.

ASP.NET requestQueueLimit

Requests for ASP.NET are queued over a pipe between IIS and the ASP.NET worker process. As clients connect to the Communicator Web Access server, ASP.NET requests accumulate on the server. The default limit for the queue at the process level is 5000, which can be reached quickly, especially as the number of users approaches 4500. The limit can be specified in the machine.config file by the requestQueueLimit attribute in the processModel element, with the following default setting:

<processModel autoConfig=true" />

When this limit is reached, ASP.NET returns the message "503 – Server Too Busy" to new requests. You can change the requestQueueLimit setting by modifying the processModel element in the machine.config file.

To change the requestQueueLimit setting

  1. In Windows Explorer, go to the following folder: *<drive>:\*WINDOWS\Microsoft.Net\Framework\v2.0.50727\CONFIG.

  2. Open the machine.config file in a text or XML editor.

  3. Locate the processModel element and update the requestQueueLimit entry. Use either of the following two examples.

    Example 1. Replace the default <processModel autoConfig="true"> element with the following entry and modify the requestQueueLimit setting:

    <processModel enable="true" requestQueueLimit="8000" />

    Example 2. Modify the requestQueueLimit setting in the existing processModel element:

    <processModel enable="true" timeout="Infinite" idleTimeout="Infinite" shutdownTimeout="0:00:05" requestLimit="Infinite" requestQueueLimit="8000" restartQueueLimit="10" memoryLimit="60" webGarden="false" cpuMask="0xffffffff" userName="machine" password="AutoGenerate" logLevel="Errors" clientConnectedCheck="0:00:05" comAuthenticationLevel="Connect" comImpersonationLevel="Impersonate" responseRestartDeadlockInterval="00:09:00" responseDeadlockInterval="00:03:00" <!-- In the .NET Framework version 2.0, the next two attributes are set to 20. --> maxWorkerThreads="25" maxIoThreads="25" />

Communicator Web Access Server Connection Type

Although Communicator Web Access supports the use of an HTTP connection between the client and server, we recommend that this HTTP traffic be secured by using SSL (HTTPS). Using SSL increases the load on the Communicator Web Access server, because the server must perform decryption. To demonstrate the impact on server capacity, two of the capacity testing scenarios used HTTP instead of HTTPS.

Other Factors Affecting Communicator Web Access Capacity

The number of legacy and federated users that a Communicator Web Access user has in his or her Contact list also affects capacity. After some investigation we have come upon this formula which gives us the relationship between capacity (which has a constant value of 90,000) and types of users in the user's contact list.

Capacity = 3*x + AvgLC*x + AvgFC*x + AvgConf*x

Where

x = Number of users

AvgLC = Average Legacy contacts per user

AvgFC = Average federated contacts per user

AvgConf = Average conference per user

Capacity = 90,000 (does not change)

As the average number of legacy contacts and federated contacts per user is reduced, the total number of users supported for a given capacity, increases.

For example, Contoso decides that they will not have any legacy contacts or federated contacts and, on average, the number of concurrent conferences per user will not be greater than 2. Substituting these values into the formula above yields:

3*x + 0+ 0 +2*x = 90,000

Hence x = 18,000

Contoso determines the number of user for the server under these conditions is 18,000 users. The server theoretically should be able to scale up to 18,000 users under these conditions.

On the other hand, if Contoso users on average have 500 legacy contacts, 500 federated contacts, and will participate in 5 conferences, on average, then using the formula yields:

3*x + 500*x + 500*x+ 5*x = 90,000

Hence x = 89 (rounded down to nearest integer)

In this case, Contoso determines that the server should handle no more than 89 users under these conditions.

Determining How Number of Users Affects Capacity

To illustrate the effect of an increased number of users on CPU and memory usage, a Communicator Web Access test deployment with the usage model previously described was tested as follows:

  • Initialize testing with 3000 users signed in.

  • Increase the number of users by increments of 250 until errors were received.

The following variables remained constant during testing:

  • 3.0 GHz dual processor with Hyperthreading enabled

  • 100 Megabit network

  • 8 GB virtual memory paging file

  • Tracing not enabled (CPU intensive)

  • 4 GB RAM (Quad-Channel, DDR2, Full Buffered DIMM, 1066 FSB)

  • 3 GB switch Off

  • Kernel-Mode SSL Off

  • HTTPS connection

  • 8000 RequestQueueLimit in ASP.NET

Table B-3 summarizes the results.

Table B-3: Number of Users on Memory Used and CPU % Used

Users Avg. Memory Max. Memory Min. Memory Avg. CPU Max. CPU Min. CPU

3000

940 MB

1165 MB

480 MB

21%

34%

3%

3250

1007 MB

1165 MB

836 MB

21.8%

39%

9.7%

3500

1031 MB

1175 MB

805 MB

27.9 %

46.4%

8.9%

3750

1060 MB

1181 MB

853 MB

33%

55%

11%

4000

1089 MB

1201 MB

791 MB

36%

59%

10%

4250

1121 MB

1213 MB

853 MB

56%

78%

24%

Conclusions of the Test

It is important to note that on a 32 bit machine, you can have a maximum of system memory (RAM) of only 4 GB (2 raised to the power of 32 – 1). By default, on any Windows machine, 2 GB is allotted for kernel and other processes. In the case of only one process running at a time, a maximum of 2 GB can be used. If that single running process is built on .NET, .NET limits internal cache of running processes (such as garbage collector and so on) to 0.8 GB. This .NET limit effectively reduces the theoretical maximum 2 GB to 1.2 GB that the Communicator Web Access 32 bit server can use.

With this limitation in mind, notice that in the preceding table, with 4000 users an average memory of 1089 MB is used. This is about 88% of the total memory based on the 1.2 GB figure; a much higher percentage than would be produced using 2GB as the total memory to calculate percent memory usage.