Share via

Estimating the Capacity of an OCS 2007 R2 Server with FSOCS

  • Article

Hi, my name is Shrey Shah and I am a developer on the Forefront Server Security team based in Long Island, NY. I work on various projects related to engine update delivery for the Forefront Server products as well as feature development for new products. I played an active role in the design and development for the Forefront for OCS release over the past year and a half.

The Office Communications Server Team provides a load simulation tool for OCS 2007 R2 deployments to aid in capacity planning. This tool can also be used to estimate the capacity of an OCS server with Forefront Server for Office Communications Server (FSOCS) installed. The remainder of this article provides a high level overview of steps an administrator can take to measure FSOCS throughput performance. These measurements can be used to estimate the capacity of a particular server given a usage model and an FSOCS configuration. It is assumed that the server hardware complies with the recommended hardware for an OCS 2007 R2 installation.

Pre-requisites

· Familiarity with Forefront Server product configuration

· OCS 2007 R2 Capacity Planning Toolkit

Configure the Test Bed

1) Install FSOCS on an OCS 2007 R2 Front-end or Standard Edition server.

 

2) Configure FSOCS with a desired set of engines as well as any other filter options that would be used in a production deployment. Make note of the number of scanning processes FSOCS is configured to use (default is 4); this value will be used later.

 

3) Install and configure the OCSLoader simulation tool according to the documentation provided by the OCS capacity planning documentation.

 

4) Configure the tool using the low or medium setting and 1000-2000 users (this assumes that the hardware being tested can sufficiently process this workload). When selecting the types of content to simulate, note that only IM traffic will be processed by FSOCS.

 

5) Before running the tool, configure the Windows Performance Monitor to capture and log the following counters:

a. Microsoft FSOCS Scan Filter : AverageProcessingTimeIMConversations

b. LC:SIP – 03 – Requests : SIP – 011 – Incoming MESSAGE Requests/sec

 

Available Counters AvailableCountersSelect

Run the Load Simulation

1) Run the load simulation for 3-4 hours (this allows for sufficient time for all the users to be logged in and produce a steady state of IM traffic).

 

2) Stop the Performance Monitor log capture.

Analyze Results

1) Open the performance monitor log.

 

2) When viewing the collected counters, notice that the “Incoming MESSAGE request/sec” counter first ramps up, then reaches a steady state. Make note of the time period in which the message rate is at steady state.

 

3) Restrict the log data view to only the time period where the message rate is at steady state.

 

4) For the specified time period, make note of the average value for the “AverageProcessingTimeIMConversations” FSOCS performance counter. This value indicates the average scanning time in seconds per IM message. For a given FSOCS configuration, the inverse of this value provides an estimate of the message throughput rate FSOCS can achieve on the given hardware per scanning process configured. For example, an average scan time of 0.018 seconds with 4 scanning processes configured (default), yields:

 

1 / 0.018 = 55 messages / sec / scanning process

55 messages / sec / scanning process * 4 scanning processes = 220 messages / sec

 

This calculation provides an estimate as to what throughput FSOCS is able to scan on the hardware the test is being run on given a specific configuration (engine selection, number of scanning processes, configured filters, etc.).

 

5) Compare the values calculated above to the average value of the “Incoming MESSAGE request/sec” OCS counter and note the relative differences.

 

6) A system with FSOCS installed on it should, on average, have an “Incoming MESSAGE request/sec” rate that is less than or equal to the calculated value above. Even though FSOCS is able to process bursts of activity where the incoming message rate exceeds its processing capacity, a system in which the average rate is higher than the capacity will experience unwanted behavior. Since instant messages should be “instant”, queuing messages isn’t a tangible option and thus a system’s throughput can go only as fast as FSOCS can scan messages.

 

By varying the simulated IM rate and/or the number of users, one can determine the maximum number of users an OCS server can support when FSOCS is installed. The table below summarizes the pre-defined usage profiles that are included as part of the OCSLoader tool. The XML file that is generated during the load simulation setup process can be modified to simulate a custom profile. Additionally, the table shows the profile based on which OCS defines its notion of “Maximum Supported Users” per server.

 

IM Usage Model Profile

Conversations/day

Conversation Length (min.)

IM Sent/Minute

IM Rate / sec / 1000 users

Low

7

120

2

20

Medium

14

120

2

40

High

24

120

2

67

Max Supported Users*

24

20

1

6

Note*:

The OCS 2007 R2 Capacity Planning documentation references a usage model based upon which supported configurations are defined. The notion of “maximum” supported users per server depends primarily on the server hardware and the usage model for IM traffic. The “Max Supported Users” profile setting is based on the user model defined in the OCS 2007 R2 Capacity Planning documentation for IM Sessions. This model is not automatically generated by the OCSLoader tool, however it is provided as a point of reference.

 

7) Once the average scanning rate of FSOCS has been determined, an administrator can estimate the number of users that can be supported by the server by using the table above or through experimentation using the OCSLoader tool. For example, if an organization’s IM usage model fits the pre-defined “medium” profile, we can use the calculated value above:

220 / 40 = 5.5 * 1000 = 5,500 users

Using the FSOCS configuration that was measured, a server similar to the one measured could support approximately 5,500 users.

Other Considerations

When going through the process described in this article, there are a number of factors to consider that can affect the potential throughput that FSOCS is able to process. The items listed below summarize some of the key variables that may affect performance; this list should not be considered all-inclusive.

· Engine Selection: Forefront provides protection from multiple antivirus engines. Each individual engine has a different performance profile and as such may have different impacts with regards to scanning throughput. Some engine selections may be better suited for the type and/or rate of traffic a particular environment processes.

 

· Number of scanning processes: FSOCS can be configured to use a varying number of scanning processes. The number of scanning processes determines the maximum number of messages that can be scanned in parallel. It is recommended that this number matches the number of CPU cores on a particular server since these processes perform CPU bound computations. By default, this value is 4, however it can be changed using the Forefront Server Administration Client.

 

· Memory Requirement: The memory footprint of FSOCS grows linearly with the number of scanning processes. That is, its requirement would be modeled as <base> + <# of Scanning Processes> * <memory / scanner>. <base> accounts for the invariable FSOCS processes such as FSCController.exe, ForefrontRTCProxy(64).exe, and ForefrontNotificationAgent.exe. The <memory / scanner> value will vary depending on the selected set of engines.

 

Process Name

Memory Utilization Pattern

FSCController.exe

Average size can be estimated by measuring size after Forefront services have been started.

ForefrontNotificationAgent.exe

Average size can be estimated by measuring size after Forefront services have been started.

FSEMailPickup.exe

Average size can be estimated by measuring size after Forefront services have been started.

ForefrontRTCProxy(64).exe

Memory utilization may vary depending on system load and the schedule of the .NET garbage collection.

FSOCScanner.exe

Memory utilization will vary depending on the selected set of engines. Total memory requirement should account for multiple instances of this process, each of which consume a similar amount of memory. Average size can be estimated by measuring the size of the process after messages have begun to flow.

 

· Enterprise Topology: FSOCS can be installed on multiple OCS server roles (i.e. Access Edge, Director, Front-end). By default, FSOCS optimizes message scanning by ensuring that messages are only scanned by a single server as it is routed from sender to recipient. The guidance above shows a methodology that allows one to measure the capacity on a server by server basis. In an enterprise topology where some considerable percentage of the traffic flows through the Access Edge and/or a Director server roles, the impact of scanning with FSOCS on the front-end (or standard edition) servers can be reduced by installing FSOCS on the Access Edge and/or Directors.

 

· Message Sizes: Typically IM messages are expected to be small. The OCSLoader tool simulates using very small messages by default. If the default message sizes are smaller or larger than what an administrator expects in their environment, these message sizes should be changed before running the simulation to give a better estimate as to how FSOCS will perform in an production setting.

· Consolidated OCS Server Roles: If an OCS server is running a consolidated configuration with multiple roles on a single server, both OCS and FSOCS will be competing for both memory and CPU. When performing the simulation described in this document, be sure to simulate traffic for any role that is expected to be consolidated with IM presence and messaging.

 

· Engine Updates and Bias Settings: FSOCS can be configured with various bias settings for antivirus scanning. For more information about each setting, please refer to the FSOCS user guide for details. By default, the bias is set to “Favor Certainty”. If the bias setting is changed to “Max Certainty”, this provides the maximum level of antivirus protection in that all selected antivirus engines are required for every message scan. Typically this does not pose an issue, however one side effect of using this setting is that when a selected engine is being updated, message scanning is suspended until the update is committed. Due to the real-time nature of instant messaging, this may have an adverse effect on the perceived user experience.

 

I hope this information will help you plan your OCS deployments with FSOCS more effectively. Feel free to use the Microsoft Forefront Security for OCS TechNet Forum to reach us.

Shrey Shah

Developer - FSS

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://useraids.com/blog/2009/04/microsoft-forefront-server-security-blog-estimating-the-capacity/

  • Anonymous
    January 01, 2003
    В блоге команды разработчиков Forefront Server Security опубликована инструкция по оценке производительности

  • Anonymous
    January 01, 2003
    Thanks for the very informative and enlightening documents. Thanks to myself every day for more of you.

  • Anonymous
    January 01, 2003
    tanhs admin abi http://www.discephemantolamafiyatlari.com

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Thank you for your expression as a table was a good expression, thank you

  • Anonymous
    January 01, 2003
    Introducing such a topic you'd like to congratulate you've let us know. Have good work...

  • Anonymous
    January 01, 2003
    çok güzel bir yazı olmuş teşekkürler devamınıda beklerim

  • Anonymous
    January 01, 2003
    çatı ustası çatıcı http://www.catici.biz

  • Anonymous
    January 01, 2003
    Alçıpan tavan asma tavan http://www.alcipanduvar.net

  • Anonymous
    January 01, 2003
    Çatı ustası http://www.firatpenfiratpen.com tahnx admin