Grundlagen der Einschränkung von Clients

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2009-04-20

Seit der Veröffentlichung von Microsoft Exchange Server 2007 steht Administratoren ein neues Feature, bekannt als RPC-Clienteinschränkung, zur Verfügung, das bei der Verwaltung der Leistungswahrnehmung beim Endbenutzer hilfreich ist. Die RPC-Clienteinschränkung wurde eingeführt, um Clientanwendungen daran hindern zu können, zu viele RPC-Vorgänge pro Sekunde an den Servercomputer mit Exchange zu senden, wodurch sonst die Servergesamtleistung sinken kann. Zu diesen Clientanwendungen gehören unter anderem Desktopsuchmaschinen, die alle Objekte im Postfach eines Benutzers durchsuchen, benutzerdefinierte Anwendungen für die Manipulation von Daten in Exchange-Postfächern, E-Mail-Archivierungsprogramme der Unternehmensklasse oder CRM-fähige Postfächer mit aktivierter automatischer E-Mail-Markierung. Die Clienteinschränkung ermöglicht es Exchange, die exklusive Belegung des Servers durch wenige Benutzer zu identifizieren und zu verhindern. Wenn vom Servercomputer mit Exchange identifiziert wird, dass ein Client unverhältnismäßige Auswirkungen auf den Server hat, kann der Server eine Backoff-Anforderung an den Client senden, um die Leistungseinbußen des Servers zu mindern.

Funktionsweise der RPC-Clienteinschränkung

Wenn die durchschnittliche RPC-Wartezeit auf dem Servercomputer mit Exchange 2007 höher als normal ist, kann es bei Benutzern des Servercomputers mit Exchange zu merklichen Dienstverschlechterungen kommen. Die durchschnittliche RPC-Wartezeit sollte unter 100 ms bleiben, damit eine akzeptable Leistung auf Benutzerseite gesichert ist.

Die RPC-Clienteinschränkung verwendet eine Rechenmethode, die auf durchschnittlichen RPC-Gesamtwartezeiten und Remotevorgangsstatistiken (ROP) basiert, anhand derer ermittelt wird, ob ein bestimmter Client Backoff-Anforderungen erhalten soll, um die Anzahl der Vorgänge zu begrenzen, die vom Client auf dem Server ausgeführt werden können. Diese Methode berechnet die durchschnittliche Verzögerung zwischen ROPs aus drei Abtastintervallen innerhalb einer bestimmten Minute. Diese Logik verwendet einen laufenden Durchschnitt der ROP-Rate für die letzte Minute. Sobald dieser Wert ermittelt ist, wird er mit der durchschnittlichen RPC-Gesamtwartezeit verglichen. Wenn der berechnete Wert niedriger als die durchschnittliche RPC-Gesamtwartezeit ist, werden Backoff-Anforderungen an den Client gesendet.

Bei einer RPC-Wartezeit von 25 ms kann ein sich im Rahmen verhaltender Client beispielsweise erfolgreich bis zu 40 ROPs pro Sekunde senden (40 * 25 = 1000 ms), ohne dass es zur Einschränkung kommt. Wenn die RPC-Wartezeit auf 100 ms erhöht wird, und der Client versucht hat, dieselbe Menge ROPs zu senden, erhält der Client Backoff-Anforderungen vom Server. Von diesem Zeitpunkt an genehmigt der Server dem Client nur noch das Senden von bis zu 10 ROPs pro Sekunde, bis der nächste durchschnittliche RPC-Wartezeitsamplewert wieder unter 100 ms liegt.

Die Logik für Backoff-Anforderungen besteht aus zwei Stufen. In der ersten wird vom Server ermittelt, ob der Client eingeschränkt werden muss, während in der zweiten bestimmt wird, dass der Zugriff auf den Server für den Client gesperrt wird. Innerhalb des Informationsspeicherdiensts ist ein Clientaktivitätsprotokoll vorhanden, das die Aktivitäten aller Benutzer auf dem jeweiligen Server verfolgt. Jedes Clientaktivitätsprotokoll ist der MAPI-Sitzung eines Benutzers zugeordnet. Wenn der Server nun die Entscheidung trifft, dass ein Client eingeschränkt werden muss, wird der Backoff-Sitzungswarteschlange eine Backoff-Anforderung für die MAPI-Sitzung dieses Benutzers hinzugefügt. Mithilfe dieser Backoff-Informationen wird dann bestimmt, ob die Clientanforderung akzeptiert oder vom Server zurückgewiesen wird. Hat der Benutzer in einer einzelnen MAPI-Sitzung mehrere Postfächer geöffnet, gelten diese Backoff-Informationen für alle Postfächer dieser MAPI-Sitzung.

In Abhängigkeit von der verwendeten Version von Microsoft Office Outlook sendet der Server verschiedene Backoff-Informationen an den RPC-Antwortdatenstrom des Clients.

• Bei Microsoft Office Outlook 2007-Clients wird der Backoff-Warteschlange des Benutzers eine ropBackoff-Anforderung hinzugefügt. Diese Anforderung enthält Informationen hinsichtlich der aktuellen Backoff-Verzögerung und fordert den Client auf, das Senden aller weiteren Anforderungen an den Server um eine bestimmte Zeit zu verzögern. Der Client unternimmt dann einen erneuten Sendeversuch für Anforderungen nach Ablauf der angegebenen Zeit. Der Maximalwert für diese Backoff-Verzögerung ist fest codiert auf 2000 ms bzw. 2 Sekunden.

  Hinweis

  Zur Erhaltung einer optimalen Clientbedienbarkeit wird empfohlen, bei einem Servercomputer mit Exchange 2007 Outlook 2007-Clients zu verwenden.

  Hinweis

  Die ropBackoff-Anforderung ist ein neues Feature in Outlook 2007, das Outlook-Clients früherer Versionen nicht verarbeiten können.

• Bei Microsoft Office Outlook 2003 oder früheren Versionen wird ein Statuscode von RPC_S_SERVER_TOO_BUSY gesendet. Dieser Statuscode simuliert die Antwort, die von Servercomputern mit Exchange 2003 an Clients gesendet wird, wenn keine RPC-Threads im Informationsspeicher mehr vorhanden sind. Die früheren Versionen sind darauf ausgelegt, diese Ausnahme abzufangen und dann für einen Zeitraum zu warten, bevor der Aufruf gemäß den Angaben in der Antwort des Servers an den Client erneut versucht wird. Die Standarddauer für diese Verzögerung ist 1 Sekunde. Wenn der Client eine Minute lang jede Sekunde versucht, die Anforderung zu senden, und dabei jedes Mal immer noch dieselbe Ausnahme erhält, bricht der Client den Versuch ab und unterbricht die Sitzung mit dem Servercomputer mit Exchange.

Überwachen auf Zustände mit vielen RPC-Vorgängen pro Sekunde

Hilfreich bei der Ermittlung, ob Clients zurückgewiesen werden, ist die Überwachung des Leistungsindikators „MSExchangeIS\RPC-Clientbackoff/Sek.“ auf den Servercomputern mit Exchange, auf denen die Serverfunktion Mailbox installiert ist, um die Rate zu bestimmen, mit der Backoff-Anforderungen auftreten.

Bei Outlook 2007-Clients, die eingeschränkt werden, können Sie erwarten, dass der Indikator „MSExchangeIS\RPC-Clientbackoff/Sek.“ ungefähr 50 Backoffs pro Sekunde für jeden Client anzeigt. Bei Outlook 2003 und früheren Versionen sollte maximal 1 Backoff pro Sekunde für jeden Client auftreten. Der Unterschied bei den zu erwartenden Raten wird vom Auflösungsvermögen der Backoff-Methode verursacht, die für den jeweiligen Client verwendet wird. Der kleinste Backoff-Zeitraum bei Outlook 2003 ist eine Sekunde, während dieser für Outlook 2007 eine Millisekunde beträgt.

Die an den Client gesendeten Backoff-Informationen bestehen aus zwei Teilen. Der erste Teil enthält die Uhrzeit, zu der die Backoff-Anforderung eingefügt wurde. Der zweite Teil ist die Dauer des Backoff-Zeitraums. Die Dauer des Backoff-Zeitraums wird auf Grundlage der folgenden Formel berechnet: ("MSExchangeIS\Durchschnittl. RPC-Wartezeit" * RPC-Einschränkungsfaktor)/1000. By default, the RPC throttling factor is a value of 1000. This means that the back-off period is exactly the value of RPC average latency. Dies bedeutet, dass der Backoff-Zeitraum genau mit dem Wert der durchschnittlichen RPC-Wartezeit übereinstimmt. Der Backoff-Wert, der vom Server an den Client gesendet wird, ist die Anzahl von Millisekunden bis zum Ablaufen des Backoff-Zeitraums. Sendet der Client vor Ablauf des angegebenen Backoff-Zeitraums einen weiteren Vorgang an den Server, gibt dieser eine weitere ropBackoff-Anforderung mit einem aktualisierten Verzögerungswert zurück. Dies geht so weiter, bis der Backoff-Zeitraum verstrichen ist, wodurch die ropBackoff-Anforderung aus der Backoff-Warteschlange des Benutzers entfernt wird. Ein Beispiel dafür, wie diese Situation im Systemmonitor aussieht, finden Sie in der folgenden Abbildung:

Optimierung bei Zuständen mit vielen RPC-Vorgängen pro Sekunde

Auf Servercomputern mit Exchange, auf denen die Serverfunktion Mailbox installiert ist, ist ein Registrierungswert verfügbar, der bei der Optimierung der Einschränkungsberechnung hilfreich ist. Dieser Registrierungsschlüssel lautet RPC Throttling Factor (RPC-Einschränkungsfaktor) und befindet sich unter dem Schlüssel HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem.

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

RPC Throttling Factor

DWORD: Kann einen Wert zwischen 0 und 5000 haben.

Zur Illustration, wie sich die Änderung des RPC-Einschränkungsfaktors auswirkt, betrachten Sie den Fall, dass Sie den Server so konfigurieren möchten, dass Clients für einen längeren Zeitraum zurückgewiesen werden sollen, wie z. B. das Doppelte der durchschnittlichen RPC-Wartezeit. Legen Sie zu diesem Zweck den RPC-Einschränkungsfaktor auf einen Wert von 2000 fest. Hierdurch wird der Backoff-Zeitraum für jede MAPI-Sitzung um den Faktor Zwei erhöht. In diesem Fall entspricht ein Einschränkungsfaktor von 2000 bei einer durchschnittlichen RPC-Wartezeit von 50 ms (50 ms * 2000/1000) dem Wert 100 ms. Jede Backoff-Anforderung wird also anstelle der standardmäßigen 50 ms auf 100 ms verlängert, wodurch zusätzliche Client-MAPI-Anforderungen an den Server um 100 ms verzögert werden. Bedenken Sie, dass eine solche Konfigurationsänderung beim Client als Verlangsamung der Serverleistung wahrgenommen werden kann. Wenn aber dieser Client negativen Einfluss auf die Gesamtleistung des Servers hat, wird die Ressourcennutzung auf dem Servercomputer mit Exchange durch diesen Client minimiert. Auf diese Weise wird die wahrgenommene Serverleistung für alle anderen Benutzer auf dem Server verbessert.

Für eine optimale Bedienbarkeit bei Verwendung dieses Einschränkungsmechanismus sollten mindestens Outlook 2007 und Exchange 2007 verwendet werden.

Die Einschränkung kann vollständig deaktiviert werden, indem der Einschränkungsfaktor auf einen Wert von 0 festgelegt wird.

Wenn Sie denken, dass eine Deaktivierung der Clienteinschränkung eventuell unerlässlich ist, empfiehlt es sich, zuerst die Ursache für den Leistungsengpass auf dem Server zu ermitteln. In den meisten Fällen führt eine Identifizierung und Behebung der Ursache dazu, dass der Server keine Backoff-Anforderungen mehr an Clients senden muss.

Weitere Informationen

Informationen zur Behandlung von Problemen bei langsamer Verarbeitung von RPC-Anforderungen finden Sie unter Behandlung von Problemen der langsamen Verarbeitung von RPC-Anforderungen.

Informationen zum Aktivieren der clientseitigen Überwachung finden Sie unter Aktivieren der clientseitigen Überwachung.