Skalierbarkeit von RPC über HTTP

Letztes Änderungsdatum des Themas: 2006-04-27

Durch RPC über HTTP erhöht sich die Auslastung des RPC-Proxyservers nur geringfügig, sodass er in seiner Leistung kaum beeinträchtigt ist.

Um diese Auslastung zu prüfen, können Sie mit Exchange Load Simulator (LoadSim) 2003 eine Simulation von Clients durchführen, die sich mit RPC über HTTP verbinden. Weitere Informationen zur Verwendung von LoadSim 2003 finden Sie unter Microsoft Exchange Server 2003 Load Simulator (LoadSim).

RPC über HTTP funktioniert optimal in Kombination mit Microsoft® Office Outlook® 2003 im Cachemodus. Zur Ausführung folgender Aufgaben sollten Sie RPC über HTTP immer im Cachemodus verwenden:

• Reduzieren der Anzahl von Verbindungen, die Outlook zum Exchange-Server eingerichtet hat.
• Abschirmen des Clients vor Internetwartezeiten.

Von Outlook eingerichtete HTTP-Sitzung unter Verwendung von RPC über HTTP

Für jede RPC-Verbindung initiiert Outlook zwei HTTP-Sitzungen: eine für ausgehende Daten und ein für eingehende Daten. Wenn Outlook fünf Verbindungen zum Exchange-Server für Postfach, Öffentliche Ordner und den Verzeichnisdienst von Exchange anzeigt, sind tatsächlich zehn HTTP-Sitzungen aktiv. Dabei besteht die Möglichkeit, dass sich im IIS-Anwendungspool (Internet Information Services) die Warteschlange mit gleichzeitigen Kernelanforderungen füllt. Wenn dies geschieht, kann die Leistung von Outlook-Clients beeinträchtigt werden.

Das folgende Beispiel zeigt, wie eine mit gleichzeitigen Kernelanforderungen gefüllte Warteschlange die Leistung des IIS-Anwendungspools beeinträchtigt. Der Standardwert für das Limit bei Kernelanforderungs-Warteschlangen ist abhängig von der Windows Server 2003-Version, die für die IIS-Aktivierung verwendet wurde. Wurde Microsoft Windows Server™2003 für die IIS-Installation verwendet, liegt das Standardlimit für Kernelanforderungs-Warteschlangen bei 4000. Bei Verwendung von Windows Server 2003 Service Pack 1 (SP1) oder höher liegt es bei 1000. In diesem Beispiel nutzt jeder Outlook-Benutzer durchschnittlich fünf RPC-Verbindungen. Dabei kann es sich um Verbindungen zum Exchange-Postfach, Öffentlichen Ordnern oder zum Verzeichnisdienst handeln Für fünf Outlook RPC-Verbindungen werden in Outlook zehn HTTP-Sitzungen pro Benutzer eingerichtet. Deshalb ist das Limit der Warteschlange bei 400 gleichzeitigen Benutzer mit je zehn HTTP-Sitzungen erreicht. Kommen weitere Benutzer hinzu, wirkt sich dies negativ auf die Leistung aus, da IIS Outlook-Sitzungen schließt. Outlook muss von IIS geschlossene Sitzungen erneut öffnen.

Weitere Informationen zum Anzeigen von in Outlook derzeit eingerichteten Verbindungen finden Sie unter Anzeigen hergestellter Outlook-Verbindungen.

Wenn Sie das Limit für Kernelanforderungs-Warteschlangen erhöhen, steigt die Speicherauslastung auf dem RPC-Proxyserver geringfügig. Windows Server 2003 Service Pack 1 (SP1) bietet Verbesserungen, die den Speicheraufwand bei einer Zunahme der Kernelanforderungen reduzieren. Wenn Sie das Limit für Kernelanforderungs-Warteschlangen hochsetzen möchten, müssen Sie das Limit auf dem RPC-Proxyserver um das Zehnfache der Anzahl gleichzeitiger Outlook-Benutzer erhöhen, die auf dem Server mit RPC über HTTP unterstützt werden sollen.

Weitere Informationen zum Erhöhen des Limits für Kernel-Anforderungswarteschlangen finden Sie unter Erhöhen des Limits für Kernel-Anforderungswarteschlangen.

Einschränkungen bei der Skalierbarkeit von RPC über HTTP

Bei der 32-Bit-Version von Windows Server 2003 mit SP1 ist die Anzahl der zuverlässig unterstützten HTTPS-Verbindungen aufgrund der Kernelspeicherauslastung, insbesondere des Nicht-Auslagerungsspeichers, begrenzt. Das Limit liegt bei 17.000 - 20.000 Verbindungen auf einem Server, der ohne /3GB-Parameter der Datei boot.ini konfiguriert wurde.

Anmerkung:
Die optimale Vorgehensweise ist die Ausführung von Exchange Server 2003-Front-End-Servern ohne /3GB-Parameter.

Entsprechend den oben aufgeführten Informationen zu Outlook- und HTTPS-Verbindungen (5 Outlook-Verbindungen mit 10 HTTPS-Verbindungen) kann ein Exchange 2003 Front-End-RPC/HTTPS-Server ungefähr 1700 - 2000 aktive Outlook 2003-Clients, die über RPC/HTTPS verbunden sind, zuverlässig bedienen. Weitere Informationen zu Exchange 2003 und Kernelspeicher finden Sie unter Troubleshooting Exchange Server 2003 Performance.

Netzwerklastenausgleich

Der Netzwerklastenausgleich (Network Load Balancing, NLB) kann zur Ausfallsicherheit und Skalierung verwendet werden. NLB verteilt Clientanfragen auf mehrere Server. Exchange Server 2003 unterstützt die Verwendung von RPC über HTTP auf Front-End-Servern, die zu NLB-Clustern gehören.

In der folgenden Tabelle werden die von NLB unterstützten Arten von Clientzugehörigkeit aufgelistet.

Wenn Sie auf den Front-End-Servern NLB verwenden, sollten Sie entweder die Einzel- oder Klasse C-Zugehörigkeit benutzen, um die Auslastung bei SSL-Sitzungen zu reduzieren.

Anmerkung:
Bei Outlook Web Access ist die Einzel- oder Klasse C-Zugehörigkeit erforderlich, wenn Sie die formularbasierte Authentifizierung anwenden.

Weitere Informationen zu NLB finden Sie unter Network Load Balancing Technical Reference.