RPC over HTTP 延展性

上次修改主題的時間： 2006-04-27

RPC over HTTP 在 RPC Proxy 伺服器上只佔很輕的負載量，應該不會對其效能造成負面影響。

若要驗證所產生的負載量，您可以使用 Exchange Load Simulator (LoadSim) 2003 來模擬透過 RPC over HTTP 連線的用戶端。如需關於如何使用 LoadSim 2003 的詳細資訊，請參閱＜Microsoft Exchange Server 2003 Load Simulator (LoadSim)＞。

在快取模式中，RPC over HTTP 與 Microsoft® Office Outlook® 2003 搭配使用的效果最佳。請永遠使用快取模式搭配 RPC over HTTP 來執行下列工作：

• 減少 Outlook 必須對 Exchange 伺服器所進行的連線數目。
• 防止用戶端發生網際網路延遲。

由 Outlook 使用 RPC over HTTP 所建立的 HTTP 工作階段

Outlook 為每個 RPC 連線，啟動兩個 HTTP 工作階段：一個是外寄資料的工作階段，一個是內送資料的工作階段。如果 Outlook 顯示有五個連線連到 Exchange 伺服器的 Exchange 信箱、公用資料夾及目錄服務，則實際上有十個 HTTP 工作階段。這可能可在網際網路資訊服務 (IIS) 應用程式集區填滿並行的核心要求佇列。如果並行的核心要求佇列若已填滿，Outlook 用戶端的效能可能會受到負面影響。

下列範例顯示，於 IIS 應用程式集區填滿並行的核心要求佇列會如何影響效能。核心要求佇列限制的預設值取決於啟用 IIS 的 Windows Server 2003 版本。如果您使用 Microsoft Windows Server™2003 來安裝 IIS，那麼預設的核心要求佇列限制是 4000。如果是使用 Windows Server 2003 Service Pack 1 (SP1) 或更新版本來安裝 IIS，則預設的核心要求佇列限制為 1000。在這個範例中，每個 Outlook 使用者平均具有五個 RPC 連線。這些連線可以連到 Exchange 信箱、公用資料夾或目錄服務。如果有五個 Outlook RPC 連線，那麼 Outlook 對每個使用者就有十個 HTTP 工作階段。因此，400 名並行使用者，每人各有十個 HTTP 工作階段，以填滿佇列。新增更多名使用者將會影響效能，因為 IIS 會強制關閉 Outlook 工作階段。Outlook 必須重新開啟 IIS 所關閉的工作階段。

如需關於如何檢視 Outlook 目前已建立連線的詳細資訊，請參閱如何在 Outlook 檢視建立的連線。

當您增加核心要求佇列限制的值時，也會略為增加 RPC Proxy 伺服器上的記憶體消耗量。Windows Server 2003 Service Pack 1 (SP1) 對於所增加的核心要求所造成的記憶體負荷量已有改善。若您要增加核心要求佇列限制的大小，必須將 RPC Proxy 伺服器上的限制增加為您期望具有 RPC over HTTP 之伺服器，所支援的並行 Outlook 使用者人數的十倍左右。

如需關於如何增加核心要求佇列限制大小的詳細資訊，請參閱如何增加核心要求佇列限制的大小。

RPC over HTTP 延展性限制

32 位元版本的 Windows Server 2003 SP1 確實能支援的 HTTPS 連線數量，會受到核心記憶體消耗量的限制 (特別是非分頁集區記憶體)。在沒有以 /3GB boot.ini 參數設定的伺服器上，其限制約為 17,000 到 20,000 個連線。

附註：
最佳作法是在沒有 /3GB 的 Exchange Server 2003 前端伺服器上執行。

根據上述所提供的 Outlook 及 HTTPS 連線資訊 (使用 10 個 HTTPS 連線的 5 個 Outlook 連線)，一個專用的 Exchange 2003 前端 RPC/HTTPS 伺服器，大約可服務 1700 到 2000 名透過 RPC/HTTPS 連線之作用中 Outlook 2003 用戶端。如需 Exchange 2003 及核心記憶體的詳細資訊，請參閱＜Troubleshooting Exchange Server 2003 Performance＞(疑難排解 Exchange Server 2003 效能)。

網路負載平衡

您可以使用網路負載平衡 (NLB) 提供備援及延展性。NLB 會將用戶端要求分配於一組伺服器上。Exchange Server 2003 支援具有前端伺服器之 RPC over HTTP 的使用，而該前端伺服器是 NLB 叢集。

下表列出 NLB 支援的用戶端相關性類型。

如果您在前端伺服器上使用 NLB，則應該使用單一 IP 相關性或類別 C 相關性來降低交涉 SSL 工作階段的負荷量。

附註：
當您使用表單架構的驗證時，Outlook Web Access 會需要類別 C 相關性的單一 IP。

如需 NLB 的詳細資訊，請參閱＜Network Load Balancing Technical Reference＞(網路負載平衡技術參考)。