Export (0) Print
Expand All
Related Help Topics
Loading
No resources found.
Related Blog Articles
Loading
No resources found.
Expand Minimize

Understanding Message Throttling

Exchange 2010
 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2011-11-07

This topic explains the message throttling options that are available in Microsoft Exchange Server 2010. It also describes enhancements to the message throttling functionality that are included in Service Pack 1 (SP1) of Microsoft Exchange Server 2010. Message throttling refers to a group of limits that are set on the number of messages and connections that can be processed by a computer that is running Exchange 2010 with either the Hub Transport server role or the Edge Transport server role installed. These limits prevent the accidental or intentional exhaustion of system resources on the transport server.

For more information about management tasks related to managing transport servers, see Managing Transport Servers.

Contents

Message Throttling Scope

Message Throttling Options on Transport Servers

Message Throttling Option on Send Connectors

Message Throttling Options on Receive Connectors

Message Throttling Policies

Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and SMTP session time-out values. These limits work together to protect a Hub Transport server or Edge Transport server from being overwhelmed by accepting and delivering messages. Although a large backlog of messages and connections may be waiting to be processed, the message throttling limits enable the transport server to process the messages and connections in an orderly manner.

In addition to message throttling, with Exchange 2010 you can also put size limits on the individual components of messages, such as the number of recipients, the size of the message header, or the size of individual attachments. For more information about message size limits, see Understanding Message Size Limits.

Another Exchange 2010 feature that helps avoid overwhelming the system resources of an Exchange 2010 transport server is back pressure. Back pressure is a system resource monitoring feature on Hub Transport servers and Edge Transport servers. When a monitored system resource, such as hard disk utilization or memory utilization, exceeds the specified threshold, the Exchange transport server reduces the rate at which it accepts new connections and messages, and focuses on delivering existing messages. When the utilization of the monitored system resources returns to normal levels, the Exchange transport server slowly increases the rate at which it accepts new connections and then establishes a normal level. For more information, see Understanding Back Pressure.

Exchange 2010 SP1 includes additional features that enhance the message throttling functionality. These enhancements address the following issues that administrators may experience in a messaging environment:

  • Because more resources are required to send messages that have large attachments or that are sent to multiple recipients, other message delivery operations may experience increased latency.

  • A high rate of mailbox delivery operations may reduce the user interactive mailbox experience. For example, users may experience slow refresh or update times when they access their mailboxes.

  • No centralized method is available to control how a specific user may inadvertently affect the resources of a Transport server. Such an effect may occur if the user sends messages that have high delivery costs in terms of number of recipients or total message size or both.

To provide more consistent message throughput and predictable message delivery latency, Exchange 2010 SP1 establishes an accumulated cost for messages. This cost is based on the following criteria:

  • Message size

  • Number of recipients

  • Frequency of transmission

Transport servers that run on Exchange 2010 SP1 track the average delivery cost of messages that are sent by individual users. By using message costs, Exchange 2010 SP1 provides a group of settings that can control the effect that a user or connection has on an Exchange organization. This group of settings is known as a throttling policy. When a user repeatedly sends costly messages, such as messages that have large attachments or messages that are sent to many recipients, the Exchange 2010 SP1-based transport servers use a throttling policy to assign a lower priority to higher-cost messages from the user while continuing to deliver lower-cost messages. This new behavior adds a “quality of service” aspect to the message throttling functionality in Exchange 2010.

noteNote:
Message throttling doesn’t affect the message priority from a user’s perspective. Messages still retain the original priority set by the user. For example, messages retain a setting of Important or Urgent, and so on.

To support this new functionality, Exchange 2010 SP1 uses the following mechanisms:

  • Internal prioritization agent This agent is triggered on the OnResolvedMessage event and assigns a lower priority to messages from the same sender that have a high accumulated cost. This cost is measured over a period of one minute and affects messages that have more than 500 P1 and P2 recipients or that are larger than 1 megabyte (MB).

  • Quota-based priority queuing for the MapiDelivery queue type This mechanism causes Exchange to deliver messages in a normal-priority queue more frequently than messages in a low-priority queue. By default, the normal-to-low message ratio is 20:1. However, new messages from a lower priority queue are never delivered sooner than new items from a higher priority queue. For example, consider the following scenario:

    1. Twenty normal priority messages are delivered. By default, the next delivered message is a lower priority message.

    2. Two new messages are received by the Transport server: One message from a higher priority queue and one message from a lower priority queue.

    In this scenario, the message from the higher priority queue is delivered first. Then, the message from the lower priority queue is delivered.

  • Throttle concurrent connections based on messaging database health This mechanism monitors the health of the Exchange messaging database (MDB) health and throttles concurrent connections to Exchange transport servers based on an assigned Health Measure value. The MDB is monitored by the Resource Health Monitor API on the Hub Transport server and is assigned a health value from -1 through 100. This value is based on the RPC performance statistics that are included with each RPC response from the Store.exe process. The Resource Health framework uses both the Requests/Second rate performance counter and the Average RPC Latency performance counter to calculate a health value for the database. To help maintain a consistent interactive user experience, Exchange reduces the number of concurrent connections as the health value decreases. The following health value ranges are available:

    • -1: This value indicates that the MDB health state is unknown. This value is assigned when the database starts. In this scenario, the database is considered healthy.

    • 0: This value is assigned if the database is in an unhealthy state. In this state, the database should not be contacted.

    • 1 through 99: These values represent a fair health state. A lower value represents a less healthy database.

    • 100: This value represents a healthy database.

The Microsoft Exchange Throttling service in Exchange 2010 SP1 provides the framework for mail flow throttling. This service is installed when you install the Mailbox Server role. The Exchange 2010 Throttling service keeps track of mail flow throttling settings for a specific user and caches the throttling information in memory. Mail flow throttling settings are also known as a budget. Restarting the Exchange 2010 Throttling service also resets mail flow throttling budgets.

You can use the throttling policy cmdlets that are available in Exchange 2010 SP1 to configure individual budget settings for a throttling policy. A budget is the amount of access that a user or application may have for a specific setting. A budget represents how many connections a user may have or how much activity a user may be permitted for each one-minute period. For example, a budget may be configured to set the amount of time that a user may spend using a specific feature in Exchange, such as ActiveSync, Outlook Web App, or Exchange Web Services. This threshold is stored in a throttling policy and defines the budget.

Time settings for a budget are set as a percentage of one minute. Therefore, a threshold of 100 percent represents 60 seconds. For example, assume that you want to specify Outlook Web App policy settings that limit the amount of time during which a user may run Outlook Web App code on a Client Access server and the amount of time the user may communicate with the Client Access server to 600 milliseconds over a one-minute period. To accomplish this, you need to set the value to 1 percent of one minute (600 milliseconds) for both of the following parameters:

  • OWAPercentTimeInCAS: 1

  • OWAPercentTimeInMailboxRPC: 1

A user who has this policy applied has a budget of OWAPercentTimeInCAS of 600 milliseconds and of OWAPercentageTimeInMailboxRPC of 600 milliseconds. In this scenario, when the user is logged into Outlook Web App, the user can run Client Access code for up to 600 milliseconds. After the 600 millisecond-period, the connection is considered over budget and the Exchange server doesn’t allow any further Outlook Web App action until one minute after the budget limit is reached. After the one-minute period, the user can run Outlook Web App client access code for another 600 milliseconds.

These Exchange 2010 SP1 features, together with the features in the release to manufacturing (RTM) version of Exchange 2010, let an Exchange administrator maintain a consistent user experience without having to deploy more servers than are required to meet the normal workload.

You can set the message throttling options at the following locations:

  • On the transport server

  • On a Send connector

  • On a Receive connector

You can set all the message throttling options that are available on Hub Transport servers or Edge Transport servers in the Exchange Management Shell. You can also set some of the same options by configuring the transport server properties in the Exchange Management Console (EMC).

The following table shows the message throttling options that are available on Hub Transport servers or Edge Transport servers.

Message throttling options on Hub Transport or Edge Transport servers

Source Parameter Description

Set-TransportServer

MaxConcurrentMailboxDeliveries

This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to deliver messages to mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the delivery of messages to any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxDeliveries parameter is 20.

Set-TransportServer

MaxConcurrentMailboxSubmissions

This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to accept messages from mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the acceptance of new messages from any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxSubmissions parameter is 20.

Set-TransportServer

MaxConnectionRatePerMinute

This parameter specifies the maximum rate at which new inbound connections can be opened to the Hub Transport server or the Edge Transport server. These connections are opened to any Receive connectors that exist on the server. The default value for the MaxConnectionRatePerMinute parameter is 1200 connections per minute.

Set-TransportServer or

Transport server properties

MaxOutboundConnections

This parameter specifies the maximum number of concurrent outbound connections that the Hub Transport server or Edge Transport server can have open at the same time. The outbound connections occur by using the Send connectors that exist on the server. The value that's specified by the MaxOutboundConnections parameter applies to all the Send connectors that exist on the transport server. The default value of the MaxOutboundConnections parameter is 1000. If you enter a value of unlimited, no limit is imposed on the number of outbound connections.

This value can also be configured using the EMC.

Set-TransportServer or

Transport server properties

MaxPerDomainOutboundConnections

This parameter specifies the maximum number of connections that an Internet-facing Hub Transport server or Edge Transport server can have open to any single remote domain. The outbound connections to remote domains occur by using Send connectors that exist on the server. The default value of the MaxPerDomainOutboundConnections parameter is 20. If you enter a value of unlimited, no limit is imposed on the number of outbound connections per domain.

This value can also be configured using the EMC.

Set-TransportServer

PickupDirectoryMaxMessagesPerMinute

This parameter specifies the rate of message processing for both the Pickup directory and Replay directory. Each directory can independently process message files at the rate that's specified by the PickupDirectoryMaxMessagesPerMinute parameter. By default, the Pickup directory can process 100 messages per minute, and the Replay directory can process 100 messages per minute at the same time.

The Pickup directory and the Replay directory scan for new message files once every 5 seconds, or 12 times per minute. This 5-second polling interval isn't configurable. This means the maximum number of messages that can be processed during each polling interval is the value that you assign to the PickupDirectoryMaxMessagesPerMinute parameter divided by 12 (PickupDirectoryMaxMessagesPerMinute/12). By default, a maximum of just over eight messages can be processed during each 5-second polling interval.

For more information, see the following topics:

The following table shows the message throttling option that's available on Send connectors that are configured in your organization or an Edge Transport server. You must use the Shell to configure this option.

Message throttling option available on Send connectors

Source Parameter Description

Set-SendConnector

ConnectionInactivityTimeOut

This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. The default value is 10 minutes.

For more information, see Set-SendConnector.

The following table shows the message throttling options that are available on Receive connectors that are configured on a Hub Transport server or an Edge Transport server. You must use the Shell to configure these options.

Message throttling options available on Receive connectors

Source Parameter Description

Set-ReceiveConnector

ConnectionInactivityTimeOut

This parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. The default value for a Receive connector that's configured on a Hub Transport server is 5 minutes. The default value for a Receive connector that's configured on an Edge Transport server is 1 minute.

Set-ReceiveConnector

ConnectionTimeOut

This parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. The default value for a Receive connector that's configured on a Hub Transport server is 10 minutes The default value for a Receive connector that's configured on an Edge Transport server is 5 minutes. The value specified by the ConnectionTimeout parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter.

Set-ReceiveConnector

MaxInboundConnection

This parameter specifies the maximum number of inbound SMTP connections that this Receive connector allows at the same time. The default value is 5000.

Set-ReceiveConnector

MaxInboundConnectionPercentagePerSource

This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The value is expressed as the percentage of available remaining connections on a Receive connector. The maximum number of connections that are permitted by the Receive connector is defined by the MaxInboundConnection parameter. The default value of the MaxInboundConnectionPercentagePerSource parameter is 2 percent.

Set-ReceiveConnector

MaxInboundConnectionPerSource

This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The default value is 100.

Set-ReceiveConnector

MaxProtocolErrors

This parameter specifies the maximum number of SMTP protocol errors that a Receive connector allows before the Receive connector closes the connection with the source messaging server. The default value is 5.

Set-ReceiveConnector

TarpitInterval

This parameter specifies the delay that's used in tarpitting. Tarpitting is the practice of artificially delaying SMTP responses for specific SMTP communication patterns that indicate a directory harvest attack or other unwelcome messages. A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization to use as a target for unsolicited commercial e-mail.

The delay that's specified by the TarpitInterval parameter only applies to anonymous connections. The default value of the TarpitInterval parameter is 5 seconds. For more information, see Understanding Recipient Filtering.

For more information, see Set-ReceiveConnector.

In Exchange 2010 SP1, each mailbox has a ThrottlingPolicy setting. The default value for this setting is $Null. You can use the Set-Mailbox command together with the ThrottlingPolicy parameter to configure a throttling policy for a mailbox.

A default throttling policy exists to provide a default set budget configuration for users who connect to Exchange. To configure customized budget settings for one or more users, create a new throttling policy. Then, apply the policy to the appropriate user or group.

importantImportant:
We recommend that you do not modify the default throttling policy.

You can set all the message throttling options that are available on Mailbox servers in the Exchange Management Shell. The following cmdlets are available to manage throttling policies:

  • Get-ThrottlingPolicy

  • Remove-ThrottlingPolicy

  • New-ThrottlingPolicy

  • Set-ThrottlingPolicy

For more information, see Understanding Client Throttling Policies.

You can use the New-ThrottlingPolicy and Set-ThrottlingPolicy cmdlets to configure how much activity a user can perform against Exchange over a specific connection or time period. These settings make up a user’s budget. You can establish throttling policies to control access to the following Exchange features:

  • Exchange ActiveSync

  • Exchange Web Services

  • Outlook Web App

  • Unified Messaging

  • IMAP4

  • POP3

  • Outlook client connections (MAPI or RPC connections)

  • Mail flow settings

  • PowerShell commands

  • CPU usages

For more information about the policy settings available for use with the throttling policy cmdlets, see New-ThrottlingPolicy and Set-ThrottlingPolicy.

For more information about how to configure Transport servers, see the following topics:

 © 2010 Microsoft Corporation. All rights reserved.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft