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.

Note:
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.