Exchange 2013 transport servers calculate an average delivery cost for the message. This cost takes into
account the size of the message, the number of recipients, and how often that user has
sent messages. High values for any or all these metrics raise the average delivery cost. In
this case, “high values” means more than 500 recipients or a message size greater than 1
MB. The Microsoft Exchange Throttling service monitors this cost and creates a budget for
each user; when a user exceeds his budget, his messages are lowered in priority so that
they take longer to transfer. (Note that that the priority imposed by the throttling service
supersedes any priority set by the user when she sends a message.) In addition to budget
calculations, the Microsoft Exchange Throttling service tabulates the Average RPC Latency
and Requests/Second counters on the mailbox database to derive a numeric health value,
indicating how much load is being placed on the database. This health value is used to bias
the amount of budget available to users on that mailbox database.
You can apply throttling parameters to the following:
● On the Transport service This is done with the Set-TransportService and
Set-MailboxTransportService cmdlets. (Some parameters can also be set through
EAC.) Typically, you only need to apply throttling to servers that deal with external
traffic, although you might have to apply throttling on transport servers positioned
on a busy hub site.
● A receive connector This is done with the Set-ReceiveConnector cmdlet. Again,
you usually only need to pay attention to the receive connectors that handle incoming traffic from outside the organization.
● A send connector This is done with the Set-SendConnector cmdlet.
The default values Exchange sets are usually sufficient for most purposes and need to be
changed only if monitoring reveals that hub transport, or edge servers are struggling to
cope with incoming traffic. For example, the situation deserves investigation if you see
large queues accumulating at peak times that do not reduce when peak times pass. This
might be caused by a simple lack of processing capacity, or it could be caused by other
conditions that you can address by tweaking the throttling parameters. Table 2-6 summarizes the different parameters you can use to control transport throttling.
account the size of the message, the number of recipients, and how often that user has
sent messages. High values for any or all these metrics raise the average delivery cost. In
this case, “high values” means more than 500 recipients or a message size greater than 1
MB. The Microsoft Exchange Throttling service monitors this cost and creates a budget for
each user; when a user exceeds his budget, his messages are lowered in priority so that
they take longer to transfer. (Note that that the priority imposed by the throttling service
supersedes any priority set by the user when she sends a message.) In addition to budget
calculations, the Microsoft Exchange Throttling service tabulates the Average RPC Latency
and Requests/Second counters on the mailbox database to derive a numeric health value,
indicating how much load is being placed on the database. This health value is used to bias
the amount of budget available to users on that mailbox database.
You can apply throttling parameters to the following:
● On the Transport service This is done with the Set-TransportService and
Set-MailboxTransportService cmdlets. (Some parameters can also be set through
EAC.) Typically, you only need to apply throttling to servers that deal with external
traffic, although you might have to apply throttling on transport servers positioned
on a busy hub site.
● A receive connector This is done with the Set-ReceiveConnector cmdlet. Again,
you usually only need to pay attention to the receive connectors that handle incoming traffic from outside the organization.
● A send connector This is done with the Set-SendConnector cmdlet.
The default values Exchange sets are usually sufficient for most purposes and need to be
changed only if monitoring reveals that hub transport, or edge servers are struggling to
cope with incoming traffic. For example, the situation deserves investigation if you see
large queues accumulating at peak times that do not reduce when peak times pass. This
might be caused by a simple lack of processing capacity, or it could be caused by other
conditions that you can address by tweaking the throttling parameters. Table 2-6 summarizes the different parameters you can use to control transport throttling.
No comments:
Post a Comment