了解用戶端節流

適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上次修改主題的時間： 2009-04-20

運用 Microsoft Exchange Server 2007 版本，系統管理員可以使用稱為 RPC 用戶端節流的新功能，協助管理使用者效能體驗。RPC 用戶端節流的引進是為了協助防止用戶端應用程式每秒將太多的 RPC 作業傳送給 Exchange 伺服器，而降低整體伺服器效能。這些用戶端應用程式包含搜尋使用者信箱內每個物件的桌面搜尋引擎、撰寫以操作位在 Exchange 信箱內資料的自訂應用程式、企業級電子郵件封存產品，或啟用電子郵件自動標記的已啟用 CRM 信箱。用戶端節流允許 Exchange 識別並協助防止一些使用者獨佔伺服器。Exchange 伺服器將用戶端識別為對伺服器造成不對稱的影響時，伺服器會將「輪詢」要求傳送給用戶端，以降低對伺服器的效能影響。

附註：
在 Microsoft Exchange Server 2003 中，具有 "Disable MAPI Client Processes" 登錄機碼 (如可用來停用執行 Exchange Server 2003 電腦之 MAPI 程式存取權的功能所述)。可能會啟用此登錄機碼，以協助鎖定特定處理程序，使其無法連線至 資訊儲存庫服務。Exchange 2007 已不再實作此登錄機碼，並取代為這個新的 RPC 用戶端節流機制。

RPC 用戶端節流的運作方式

如果 Exchange 2007 伺服器上的 RPC 平均延遲高於正常值，則 Exchange 伺服器使用者可能會注意到服務明顯惡化。RPC 平均延遲應該保持低於 100 毫秒，以維護可接受的使用者體驗。

RPC 用戶端節流使用的計算方法是根據整體 RPC 平均延遲和遠端作業 (ROP) 統計資料，用來判斷指定用戶端是否開始接收輪詢要求，以限制用戶端可以對伺服器執行的作業數目。此方法會計算不同 ROP 在三個取樣期間的指定分鐘期間的平均延遲。此邏輯使用最後一分鐘 ROP 速率的輪流平均。此值決定之後，接著會與整體 RPC 平均延遲進行比較。如果此計算值低於整體 RPC 平均延遲，則會將輪詢要求傳送給用戶端。

重要事項：
只要最後一分鐘的平均 RPC 延遲低，則每秒高 ROPS 的短暫突增並不會將輪詢要求傳送給用戶端。

例如，如果您的 RPC 延遲是 25 毫秒，則正常執行的用戶端每秒最高可以順利傳送 40 個 ROPS (40*25=1000 毫秒)，而不需要使用節流。如果 RPC 延遲增加為 100 毫秒，且用戶端嘗試傳送相同數量的 ROPS，則用戶端會開始接收到來自伺服器的輪詢要求。從此時開始，在下一個 RPC 平均延遲範例再次低於 100 毫秒之前，伺服器只會允許用戶端每秒最多傳送 10 個 ROPS。

輪詢要求的邏輯有兩個主要部分。第一個部分是伺服器如何決定用戶端的節流，而第二個部分是封鎖用戶端使其無法存取伺服器的判定。在資訊儲存庫服務內，用戶端活動記錄會記錄每位使用者對任何指定伺服器的活動。每個用戶端活動記錄都會有關聯的使用者 MAPI 工作階段。如果伺服器決定對用戶端進行節流處理，則會將輪詢要求新增至該使用者 MAPI 工作階段的工作階段輪詢佇列。然後，會使用此輪詢資訊來判斷伺服器會接受還是拒絕用戶端要求。如果使用者對單一 MAPI 工作階段開啟多個信箱，則此輪詢資訊會套用至該 MAPI 工作階段的所有信箱。

根據使用的 Microsoft Office Outlook 版本，伺服器會將不同的輪詢資訊傳送給用戶端的 RPC 回應資料流。

• 如果是 Microsoft Office Outlook 2007 用戶端，會將 ropBackoff 要求新增至使用者的輪詢佇列。此要求包含目前輪詢延遲的相關資訊，並會告知用戶端延遲一段指定時間，不要將其他任何要求傳送給伺服器。用戶端接著會在指定的時間過後重試傳送要求。此輪詢延遲的最長時間已硬式編碼為 2000 毫秒或 2 秒。

  附註：
  建議您對 Exchange 2007 伺服器使用 Outlook 2007 用戶端，以獲取最佳用戶端體驗。

  附註：
  ropBackoff 是 Outlook 2007 的新功能，舊版 Outlook 用戶端並不了解此功能。

• 如果是 Microsoft Office Outlook 2003 或舊版本，會傳送 RPC_S_SERVER_TOO_BUSY 狀態碼。此狀態碼會模仿 Exchange 2003 伺服器在 Information Store RPC 執行緒用完時傳送給用戶端的回應。舊版本是設計為偵測此例外狀況，然後在如伺服器給用戶端的回應中所指定重試呼叫之前，等待冗長的時間。此延遲的預設時間是 1 秒。如果用戶端在一分鐘的時間內每秒都嘗試要求，還是每次都接收到相同的例外狀況，則用戶端會放棄並中斷其工作階段與 Exchange 伺服器的連線。

監視每秒高 RPC 作業狀況

為了協助偵測用戶端的輪詢時間，可以在已安裝 Mailbox server role 的 Exchange 伺服器上監視 "MSExchangeIS\RPC Client Backoff/sec" 效能計數器，以判斷進行輪詢要求的速率。

如果是正在進行節流的 Outlook 2007 用戶端，則可以預期 "MSExchangeIS\RPC Client Backoff/sec" 計數器針對每個用戶端每秒大約顯示 50 個輪詢。如果是 Outlook 2003 和舊版本，則應該預期每個用戶端最多每秒 1 個輪詢。預期速率的差異在於個別用戶端所用的輪詢方法精細度。Outlook 2003 的最小輪詢期間是 1 秒，而 Outlook 2007 的最小輪詢期間是 1 毫秒。

將輪詢資訊傳送給用戶端時，資料包含兩個部分。第一個部分是插入輪詢的時間。第二個部分是輪詢期間的持續時間。輪詢期間的持續時間是根據下列公式計算而來：(MSExchangeIS\RPC 平均延遲 * RPC 節流係數)/1000。RPC 節流係數的值預設為 1000。這表示輪詢期間就是 RPC 平均延遲的值。而伺服器傳送給用戶端的輪詢值是輪詢期間過期之前的毫秒數。如果用戶端在指定的輪詢期間過期之前將另一個作業傳送給伺服器，則伺服器會傳回另一個內含更新延遲值的 ropBackoff。在輪詢期間過期之前，這種情況會持續發生，藉此從使用者的輪詢佇列移除 ropBackoff。下圖為與效能監視器類似的範例：

調整每秒高 RPC 作業狀況

在已安裝 Mailbox server role 的 Exchange 伺服器上，有一登錄機碼可用來協助調整節流計算。此登錄機碼稱為 RPC Throttling Factor，位在 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 機碼下方。

附註：
預設不會設定此值，而且必須在先前提及的機碼下方以 DWORD 值新增此值。

[HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem]

RPC Throttling Factor

DWORD：範圍可以是 0-5000 之間的值

若要顯示 RPC Throttling Factor 修改的運作方式，請考慮想要設定伺服器輪詢用戶端一段較長期間 (如 2 x RPC 平均延遲) 的狀況。做法是將 RPC Throttling Factor 設定為值 2000。這樣會以係數 2 增加每個 MAPI 工作階段的輪詢期間。在此情況下，如果 RPC 平均延遲是 50 毫秒，則節流係數 2000 (50 毫秒 * 2000/1000) 會等於 100 毫秒。每個輪詢要求都會擴充至 100 毫秒，而不是預設值 50 毫秒，因此會延遲 100 毫秒的時間不要將其他用戶端 MAPI 要求傳送給伺服器。請注意，這類組態變更對用戶端而言就是緩慢的伺服器效能。不過，如果此用戶端會對整體伺服器效能產生不利的影響，則會將此用戶端在 Exchange 伺服器上的資源使用減到最少。這樣可以改善伺服器上其他所有使用者認知的伺服器效能。

重要事項：
如果伺服器上的許多或所有用戶端都發生此問題，則應該進行伺服器端調查，以偵測是否發生任何瓶頸。

如果要獲得使用此節流機制的最佳體驗，建議至少使用 Outlook 2007 和 Exchange 2007。

將節流係數設定為值 0，就可以一併停用節流。

重要事項：
不建議您停用資訊儲存庫中的用戶端節流。進行這項變更會讓執行效能欠佳的用戶端降低任何指定伺服器上的效能。

如果您認為必須停用用戶端節流，則建議您先判斷伺服器上的效能瓶頸原因。在大部分情況下，原因的識別和解決都可以解決伺服器將輪詢要求傳送給用戶端的需求。

相關資訊

如需如何疑難排解緩慢 RPC 要求處理問題的相關資訊，請參閱疑難排解緩慢 RPC 要求處理問題。

如需如何啟用用戶端監視的相關資訊，請參閱如何啟用用戶端監視。

若要確保您目前閱讀的是最新資訊，並尋找其他的 Exchange Server 2007 說明文件，請造訪 Exchange Server 技術資源中心.