Throttling

Bis Exchange 2007 konnte jeder Client (fast) so viele Anfragen pro Sekunde an den Server senden, wie er wollte. Solange er gültige Anmeldedaten vorzuweisen hatte, hat Exchange versucht diese Anfragen zu beantworten. Aber in Bezug auf MAPI hat Exchange schon früher allzu rücksichtslosen Clients die Schranken aufgezeigt, indem es erste absolute Grenzwerte eingeführt hat, was im Eventlog Eintrag Nr. 9646 angezeigt wurde.

Event 9646

Exchange 2010 hat dieses Verfahren nun umfangreich verbessert, was sicher auch daran liegt, dass mit der Cloud (Office 365) und Hosted Lösungen der Client eben nicht mehr so kontrolliert werden kann, wie das firmenintern möglich ist. Der Client ist nun Kunde und statische Grenzen sind hier nicht mehr der richtige Ansatzpunkt.

Wie funktioniert Throttling?

Exchange 2010 und neuer „schützt“ sich gegen Missbrauch und Überlastung, indem es mit Throtting arbeitet. Stellen Sie sich Throttling wie ein Girokonto vor. Regelmäßig werden Einzahlung vorgenommen, bis ein Maximalbetrag erreicht ist. Jede Anfrage an Exchange „kostet“ aber, so dass der Kontostand reduziert wird. Wenn der Kontostand 0 ist, dann bedient Exchange diesen Anwender nicht mehr, bis der Kontostand wieder erhöht wurde.

So kann ein Client  zwar in kurzer Zeit auch viele Anfrage stellen aber muss auch wieder Pausen einlegen. für „normale Anwender“ ist dies kein Problem aber sehr wohl für automatisierte Prozesse und Dienste, die mehrere Postfächer auf einen Schlag öffnen oder viele Postfach "abscannen", z.B.

  • Blackberry Server
    Da dieser Server ja in jedes Postfach hineinschaut und den Posteingang und Kalender überwacht bzw. abscannt.
  • Archivserver
    Diese laufen oft Nachts alle Postfächer ab, um "archivwürdige" Elemente zu finden
  • SingleItemExports/Backups
    Firmen, die weder Archivprodukte noch Recovery Storage Groups oder Programme wie Ontrack Powercontrols verwenden, sichern oft per Backupprogramm in verschiedenen Abständen die einzelnen Mails (Einzelelementsicherung)
  • CDO-Anwendungen
    Das gleiche gilt natürlich auch für meine Skripte wie TerminCount, MBReport oder Programme wie EXMERGE etc., die mit einer Drosselung natürlich deutlich langsamer laufen oder gar abbrechen. Das scheint wohl auch etwas mit der eingesetzten CDO-Version zu tun zu haben.
  • CRM-Connectoren
    Die z.B.: Kontakte und Termine in den Postfächern des Benutzers stellvertretend verwalten

Ideal wäre es, wenn der Lieferant entsprechende Werte liefern kann, z.B. Anzahl der erwarteten Anfragen. Alternativ können die Standardwerte einfach genutzt werden und über das Monitoring oder die Applikation selbst fällt auf, wenn das Throttling ein Problem wird. Leider fallen solche Probleme erst auf, wenn die Last zunimmt, d.h. in der Regel nicht beim Entwickler im Testfeld oder bei der PilotUmsetzung beim Kunden. Wenn dem Dienstkonto und der Software „vertraut“ wird, kann das Limit für dieses Konto auch entfernt werden. Exchange 2007 und früher hatten dieses Throttling gar nicht.

Transport Throttling

Die erste Begrenzung, die von Betreibern von Mailsystemen gerne umgesetzt wird, ist die Beschränkung bei der Anzahl der Messages und SMTP-Verbindungen. Diese "Einfallstore" sind gerade für Spammer, Offene Relais etc. interessant, um in kürzester Zeit sehr viele Mails zu versenden. Leider sind dies natürlich auch die grundeigensten Anwendungsfälle eines Newsletter-Service, von Benachrichtigungsfunktionen einer Monitoring-Lösung oder z.B. eines Portals. Normale Anwender hingegen senden vielleicht 20-100/Mails pro Tag aber selten mehr als 10/Minute, wenn man mal von Quittungen, OOF-Meldungen und Termin zusagen absieht.

Die meisten Anwender nutzen sowieso authentifizierte Verbindungen per RPC (MAPI) oder HTTPS (OWA; EWS, ActiveSync) und gar nicht native SMTP. Insofern sind Limits auf SMTP-Empfangsconnectoren primäre zur Kontrolle von extern zugesendeten Mails oder von internen Prozessen abzustimmen. Diese Limits werden auf dem Receive Connector aktiviert. per Default sind diese nur auf Connectoren zum Empfang aus dem Internet (Edge) aktiv aber nicht bei internen Hub/Transport-Rollen

Parameter Default Bewertung

MaxInboundConnections

5000

Das ist die maximale Anzahl, die ein Connector parallel bedient.

MaxAcknowledgementDelay

30 Sek

Dieser Parameter wird gerne mit einer "verlangsamten Zustellung" in Verbindung gebracht, insbesondere wenn Warteschlangen "voll" sind. Er ist aber gar nicht zum Drosseln da, sondern verzögert eine Einlieferung nur von Hosts, die die Funktion "Shadow Redundancy" nicht unterstützen. Exchange lässt den einliefernden Host nach dem Ende der Mail warten, bis Exchange die Mail selbst schon an den nächsten Host weiter gegeben hat. So verliert der Ausfall eines Hub-Service seinen Schrecken, weil kein Mail verloren geht. Für einen fremden einliefernden Host sieht es aber so aus, als wäre Exchange "langsam"

MessageRateLimit

unlimited

Gibt die Anzahl der Nachrichten (nicht Connection) pro Minute an, die von einer mit dem Parameter "MessageRateSource " definierten Quelle gesendet werden können.

MessageRateSource

IP-Adress

Die MessageRate kann anhand der IP-Adresse, des "Mail From"-Users oder beiden Kriterien ermittelt werden.

MaxInboundConnectionPerSource

100 (Stück)

Exchange akzeptiert per Default nur 100 gleichzeitige Verbindungen von einer IP-Adresse. Ein normaler Versendeprozess sollte damit keine Probleme haben. Knifflig wird es aber, wenn Sie SMTP über einen Loadbalancer leiten, der die Source-IP-Adresse per NAT umsetzt (Single Arm Konfiguration beim LB). Dann scheinen alle SMTP-Verbindungen vom Loadbalancer zu kommen.

MaxInboundConnectionPercentagePerSource

2 (%)

Zusätzlich schaut Exchange noch, wie viele verfügbare Verbindungen möglich sind (Default 5000 - aktuelle Verbindungen) und erlaubt einer IP-Adresse dann maximal diese prozentuale Anzahl an neuen Verbindungen.

TarpitInterval

00:00:05

Tarpitting ist ein effektiver Weg, über SMTP z.B. eine Liste der gültigen Adressen zu erhalten. Exchange bestraft jeden SMTP-Befehl, der mit einem Fehler quittiert wird, mit einer Verzögerung von 5 Sekunden. Wer Mails an mehrere Empfänger versendet und dabei auch ungültige Mailadressen ansprechen will, wird also auch "gebremst".

MaxProtocolErrors

5

Wenn sich mehr "Protokollfehler" als der konfigurierte Grenzwert angesammelt haben, wird die Verbindung unterbrochen.

Leider sind diese Werte immer nur "Pro Connector" aktiv. Es gibt keine Beschränkungen, die Organisationsweit z.B. über eine Hub-Transport-Regel erfasst und gesteuert wird.

SMTP Submission Throttling

Neben den Connectoren gibt es auch für das Postfach die Möglichkeit über die Throttling Policies pro Benutzer ein Limit zu setzen. Laut Dokumentation betrifft allerdings nur Einlieferungen von POP/IMAP-Client per SMTP und keine Outlook/OWA/ActiveSync Verbindungen.


https://learn.microsoft.com/en-us/powershell/module/exchange/set-throttlingpolicy?view=exchange-ps#-messageratelimit

Auf https://www.slipstick.com/exchange/limit-number-of-internet-messages-user-can-send/ wird zwar beschrieben dass auch per OWA und Outlook die Mails dann einfach länger im Postausgang liegen, aber das konnte ich mit Exchange 2016/2019 nicht mehr nachvollziehen. Eine Limitierung per SMTP ist hier also nur der Anfang.

Sie können pro Postfach immer nur genau eine Throttling Policy anwenden. Wenn Sie bislang noch keine ThrottlingPolicy nutzen, dann können Sie eine neue Policy anlegen und individuellen Benutzern zuweisen, z.B. mit:

New-ThrottlingPolicy `
   -Name "LimitSMTP_5MailperMin" `
   -MessageRateLimit 5

Set-Mailbox <user> `
   -ThrottlingPolicy LimitSMTP_5MailperMin

Eine globale Einstellung erreichen Sie mit:

New-ThrottlingPolicy `
   -Name LimitSMTP_5MailperMin `
   -MessageRateLimit `
   -ThrottlingPolicyScope Organization

Bedenken Sie aber, dass dieses Limit alle vom Benutzer versendeten Mails betrifft, d.h. sowohl intern als auch extern.

Ich habe in meiner Lab-Umgebung mit mal ein Limit von 1 Mail/Stunde gegeben aber konnte auch nach einem Neustart der Dienste weiter mehrere Mails absenden. Ich konnte noch nicht genau ermitteln, nach welcher Zeit das Limit dann wirklich umgesetzt wird, d.h. wie schnell Exchange eine Überschreitung erkennt.

RPC Throttling

Die ersten Anwender die durch das Throttling behindert wurden, waren Outlook 2003 Clients mit Exchange 2010 Postfach. Outlook 2003 konnte nicht mit der Verweigerung von Exchange umgehen und hat zudem noch sehr viele Verbindungen geöffnet. Modernere Clients wie Outlook 2007/2010 "verstehen" diesen Wink und können mit der Fehlerbedingung umgehen. Alte Outlook Clients hingegen tun sich da schon schwerer und reagieren empfindlicher. Schließlich können Sie nicht den Fall, dass sie einen ganz normalen Zugriff auf den Server durchführen und einen Fehler erhalten. Die Effekte sind sehr unterschiedlich, weil die Ablehnung durch den Exchange Server ja an jeder Stelle passieren kann.

per Default ist z.B. der Wert für "rcamaxconcurrency " auf 20 gestellt. Folgender PowerShell-Befehl erhöht dies auf 32.

Get-throttlingpolicy | set-throttlingpolicy -rcamaxconcurrency 32

Es sind angeblich Werte bis 100 oder sogar "$null" um keine Limits zu setzen. Allerdings setzt man damit den Server natürlich wieder einer höheren Gefahr aus. Besser ist es daher vorher erst einmal zu sehen, ob diese Grenzen zutreffend sind.

Mit Service Pack 1 für Exchange Server 2010 können für RCAMaxConcurrency nun Werte bis 2147483647 verwendet werden.

Um z.B. "Effekte in Outlook 2003" bei einem bestimmten Benutzer zu finden, sollte folgendes helfen:

Get-LogonStatistics -Identity mailboxname | fl applicationid

Danach sollten Sie die Anzahl der Zeilen zählen, die z.B. auf "ApplicationID : Client=MSExchangeRPC" lauten. Wenn es als 20 oder nahe dran sind, dann dürfte der User tatsächlich hier an ein Limit gestoßen sein.

Alternativ können Sie eine neue Policy anlegen und diese ausgewählten Postfächern zuweisen. Dies ist z.B. für Migrationskonten, Blackberrry und andere Systeme interessant

New-ThrottlingPolicy ‘NoLimit' 
Set-ThrottlingPolicy ‘NoLimit' `
    -RCAMaxConcurrency $Null ` `
    -PowerShellMaxConcurrency $Null
Set-Mailbox mailboxname -ThrottlingPolicy ‘NoLimit'

Damit wird nur diese eine Mailbox von dem Limit befreit.

EWS Throttling

Immer mehr diese automatisierten Dienste nutzen statt CDO die neue EWS-Schnittstelle. Auch diese API ist natürlich mit Limits versehen. Hier die Standards von Exchange 2010

[PS] C:\>Get-ThrottlingPolicy | fl name,*ews*
 
Name                          : DefaultThrottlingPolicy
EWSMaxConcurrency             : 10
EWSPercentTimeInAD            : 50
EWSPercentTimeInCAS           : 90
EWSPercentTimeInMailboxRPC    : 60
EWSMaxSubscriptions           : 5000
EWSFastSearchTimeoutInSeconds : 60
EWSFindCountLimit             : 1000

Auch diese Werte werden im Normalfall von Anwendern nicht erreicht. für einen Dienst könnten Sie die Einstellungen wie folgt komplett frei geben

New-ThrottlingPolicy ‘NoEWSLimit' 
Set-ThrottlingPolicy ‘NoEWSLimit' `
  -EWSMaxConcurrency: $null `
  -EWSPercentTimeInAD: $null `
  -EWSPercentTimeInCAS: $null `
  -EWSPercentTimeInMailboxRPC: $null `
  -EWSMaxSubscriptions: $null `
  -EWSFastSearchTimeoutInSeconds: $null `
  -EWSFindCountLimit: $null

Set-Mailbox mailboxname -ThrottlingPolicy ‘NoEWSLimit'

Da ein Dienstkonto aber nicht immer “nur” EWS nutze, sondern auch andere Funktionen ist es sinnvoller eine spezifischere Policy zu erstellen, die das generelle Nutzungsverhalten abbildet und nicht nur wie im Beispiel EWS komplett frei gibt.

NOTE: Even after the EWS Throttling Policy has been updated, EWS imports will still be limited to 150MB per 5 minutes per mailbox; to achieve higher migration throughput speeds, please migrate more users concurrently.
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web-services/ews-throttling-in-exchange

Throttling und PowerShell

EWS und MAPI sind aber nur zwei Bereiche des Throttling. Eine einzelne Richtlinie fasst alle für den Client erreichbaren Dienste zusammen. Sie können sogar pro Dienstkonto eine eigene Policy anlegen. Sinnvoller ist es aber bestimmte Anwenderprofile als Policy zu grupperen.

[PS] C:\>Get-ThrottlingPolicy |fl
 
RunspaceId                                : <GUIDS>
IsDefault                                 : True
AnonymousMaxConcurrency                   : 1
AnonymousPercentTimeInAD                  :
AnonymousPercentTimeInCAS                 :
AnonymousPercentTimeInMailboxRPC          :
EASMaxConcurrency                         : 10
EASPercentTimeInAD                        :
EASPercentTimeInCAS                       :
EASPercentTimeInMailboxRPC                :
EASMaxDevices                             : 10
EASMaxDeviceDeletesPerMonth               :
EWSMaxConcurrency                         : 10
EWSPercentTimeInAD                        : 50
EWSPercentTimeInCAS                       : 90
EWSPercentTimeInMailboxRPC                : 60
EWSMaxSubscriptions                       : 5000
EWSFastSearchTimeoutInSeconds             : 60
EWSFindCountLimit                         : 1000
IMAPMaxConcurrency                        :
IMAPPercentTimeInAD                       :
IMAPPercentTimeInCAS                      :
IMAPPercentTimeInMailboxRPC               :
OWAMaxConcurrency                         : 5
OWAPercentTimeInAD                        : 30
OWAPercentTimeInCAS                       : 150
OWAPercentTimeInMailboxRPC                : 150
POPMaxConcurrency                         : 20
POPPercentTimeInAD                        :
POPPercentTimeInCAS                       :
POPPercentTimeInMailboxRPC                :
PowerShellMaxConcurrency                  : 18
PowerShellMaxTenantConcurrency            :
PowerShellMaxCmdlets                      :
PowerShellMaxCmdletsTimePeriod            :
ExchangeMaxCmdlets                        :
PowerShellMaxCmdletQueueDepth             :
PowerShellMaxDestructiveCmdlets           :
PowerShellMaxDestructiveCmdletsTimePeriod :
RCAMaxConcurrency                         : 20
RCAPercentTimeInAD                        : 5
RCAPercentTimeInCAS                       : 205
RCAPercentTimeInMailboxRPC                : 200
CPAMaxConcurrency                         : 20
CPAPercentTimeInCAS                       : 205
CPAPercentTimeInMailboxRPC                : 200
MessageRateLimit                          :
RecipientRateLimit                        :
ForwardeeLimit                            :
CPUStartPercent                           : 75
AdminDisplayName                          :
ExchangeVersion                           : 0.10 (14.0.100.0)
Name                                      : DefaultThrottlingPolicy_<GUID>
DistinguishedName                         : CN=DefaultThrottlingPolicy_<GUID>,CN=Global Settings,CN=ORG,
                                              CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=
                                            msxfaq,DC=net
Identity                                  : DefaultThrottlingPolicy_cc833136-e272-4364-9a6e-94b057336d6b
Guid                                      : b4ad283e-3ff4-4f05-8b31-1e0181a396b1
ObjectCategory                            : msxfaq.net/Configuration/Schema/ms-Exch-Throttling-Policy
ObjectClass                               : {top, msExchGenericPolicy, msExchThrottlingPolicy}
WhenChanged                               : 9/22/2011 8:04:47 AM
WhenCreated                               : 12/14/2009 9:56:04 AM
WhenChangedUTC                            : 9/22/2011 6:04:47 AM
WhenCreatedUTC                            : 12/14/2009 8:56:04 AM
OrganizationId                            :
OriginatingServer                         : dc1.msxfaq.net
IsValid                                   : True

Ein Postfach kann immer nur genau eine Richtlinien haben, die Sie mit Set-Mailbox zuweisen

Set-Mailbox mailboxname -ThrottlingPolicy ‘Policyname'

Beim Entfernen einer Throttling-Policy prüft Exchange ab, ob diese nicht noch einer Mailbox zugewiesen ist

[PS] C:\>Remove-ThrottlingPolicy Testpolicy
Throttling policy "CN= Testpolicy,CN=Global Settings,CN=org,CN=Microsoft Exchange,
CN=Services,CN=Configuration,DC=msxfaq,DC=net" can't be removed because there are 
currently Users associated with the policy. Reset the throttling policy für those Users using Set-Mailbox, and then try again.
    + CategoryInfo          : InvalidOperation: (:) [Remove-ThrottlingPolicy], CannotRemoveAss...PolicyException
    + FullyQualifiedErrorId : 8940A041,Microsoft.Exchange.Management.SystemConfigurationTasks.RemoveThrottlingPolicy

Ein Report, welcher Benutzer welche Richtlinie hat, können Sie auf zwei Wege ermitteln. Einmal per PowerShell mit get-Mailbox, wobei sie hier sogar Filter angeben können.

Achtung: Die Filter sind tückisch. Speziell der Filter "ThrottlingPolicy " wird in Hilfe über filterbare Properties gar nicht aufgeführt. Aber er ist vorhanden und geht zumindest für True/False.

# funktioniert NICHT (Exchange 2010 SP3)
get-mailbox -Filter {ThrottlingPolicy -eq "Policyname"}

# Der Filterparameter kann aber genutzt werden um "nicht Default" Mailboxen zu finden
get-mailbox -Filter {ThrottlingPolicy -ne $null} | fl name, alias, Throttlingpolicy

# Letztlich koppelt man die Abfrage
get-mailbox -Filter {ThrottlingPolicy -ne $null} `
   | where {$_.ThrottlingPolicy -eq "Polcyname"} `
   | fl name, alias, Throttlingpolicy

Ein zweiter Weg ist das Commandlet "Get-ThrottlingPolicyAssociation", welches für einen Benutzer die ThrottlingPolicyId mitliefert:

[PS] C:\>  Get-ThrottlingPolicyAssociation decar
 
RunspaceId         : 
ObjectId           : msxfaq.net/Users/Carius Frank
ThrottlingPolicyId :
Name               : Carius Frank
IsValid            : True
ExchangeVersion    : 0.10 (14.0.100.0)
DistinguishedName  : CN=Carius Frank,OU=Users,DC=msxfaq,DC=net
Identity           : msxfaq.net/Users/Carius Frank
Guid               : 
ObjectCategory     : msxfdaq.net/Configuration/Schema/Person
ObjectClass        : {top, person, organizationalPerson, User, inetOrgPerson}
WhenChanged        : 11/13/2010 2:07:40 PM
WhenCreated        : 1/30/2010 6:19:29 PM
WhenChangedUTC     : 11/12/2013 3:07:40 PM
WhenCreatedUTC     : 1/30/2010 5:19:29 PM
OrganizationId     :
OriginatingServer  : dc1.msxfaq.net

Natürlich steht die Information über die Policies auch im Active Directory und könnte da per LDAP-Suche ermittelt werden.

Throttling im Performance Monitor

Wie jeder ordentlicher Prozess erweitert Microsoft Exchange die Performance Counter auch für das Throttling. Eine ganze Menge von Countern gibt es für die verschiedenen Instanzen. Wobei ich bislang immer nur "PowerShell" und "rca" als Instanzen gesehen habe.

Hier einmal ein kompletter Auszug der Counter und der Beispielwerte auf meinem Exchange Spielserver. Das sind sicher keine repräsentativen Werte.

Insofern können Sie auch hierüber einen ersten Einblick erhalten, ob Throttling für ihre Umgebung ein Thema ist.

Throttling Limits erkennen

Microsoft hat auch noch einen Eventlog Eintrag mit diesem Ereignis verbunden. Sie können also gezielt danach suchen.

Ereignistyp: Fehler 
Ereignisquelle: MSExchange ADAccess 
Ereigniskategorie: Allgemein 
Ereigniskennung: 2915 
Computer: SRV01 
Beschreibung: 
Process Microsoft.Exchange.Addressbookservice.exe (PID=123). 
User 'SID~xxxxx' has gone over budget '122' times für component 'RCA' within one minute perion. 
Info: 'Policy:<policyname>, Parts AD:165;'. Threshold value:'100'.

Ähnliche Events gibt es auch für andere Dienste und Prozesse und nicht vergessen werden darf natürlich auch der Event 9646.

Ein MAC-Client wird z.B. wie folgt gelistet (Umbrüche zur Lesbarkeit addiert)

Log Name:      Application
Source:        MSExchange ADAccess
Event ID:      4023
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX2016
Description:
Process w3wp.exe (EWS) (PID=106152). 
The budget for user 'Sid~S-1-5-21-123456-123456-123456-123456~Ews~false~MacOutlook/16.16.6.190114 
   (Intelx64 Mac OS X Version 10.14.3 (Build 18D109))' 
is locked out until 8/29/2018 1:18:36 PM.  
Max Burst: 300000, Recharge Rate: 1800000, CutoffBalance: 0

Throttling im IIS

Für den Zugriff von Anwendern über die Exchange WebDienste gibt es noch eine weitere Informationsquelle. Im IISLog landen nicht nur die Zugriffe selbst sondern auch ausführliche Informationen über die angewendete Richtlinie und das aktuelle Budget. Zur Lesbarkeit habe ich IP-Adresse, Zeitstempel etc. weggelassen. Dies ist nur der Inhalte des Feldes "CS-URI-QUERY".

Hier erst eine ActiveSync-Anfrage: (POST /Microsoft-Server-ActiveSync/default.eas)

User=fcarius&
DeviceId=ApplDLXH50ZZDVD2&
DeviceType=iPad&
Cmd=Ping&
Log=V141_LdapC1_LdapL16_Hb1742_S3_
Error:PingCollisionDetected_Mbx:MB1.msxfaq.net_
Throttle0_Budget:(D)Conn%3a1
%2cHangingConn%3a0
%2cAD%3a%24null%2f%24null%2f0%25
%2cCAS%3a%24null%2f%24null%2f1%25
%2cAB%3a%24null%2f%24null%2f0%25
%2cRPC%3a%24null%2f%24null%2f1%25
%2cFC%3a1000%2f0
%2cPolicy%3aDefaultThrottlingPolicy%5Fcc833136-e272-4364-9a6e-94b057336d6b
%2cNorm_

Und eine EWS-Anfrage (POST /ews/exchange.asmx)

Requester=S-1-5-21-123-12345678-12345678-19076;local=1;
Threads.Worker.Available=399;
Threads.Worker.InUse=0;
Threads.IO.Available=400;
Threads.IO.InUse=1;
Failures=0;
MailboxRPC.TimeTaken=0;
MailboxRPC.RequestCount=0;
AD.TimeTaken=0;
AD.RequestCount=2;
Request.CPU.Main=15;
Local.FirstThreadExecute=0;
Local.LongPole.Elapsed.TimeTaken=39;
Local.LongPole.Elapsed.Destination=MB1.msxfaq.net;
LocalLongPole.TimeTaken=3;
LocalLongPole.RequestCount=15;
LocalLongPole.Destination=MB1.msxfaq.net;
TotalLocal.TimeTaken=39;
TotalLocal.RequestCount=1;
Thread.CPU.LongPole.TimeTaken=0;
Thread.CPU.LongPole.Destination=LocalRequest.Execute;
Request.Phase.PreQuery=15;
Request.Phase.RequestDispatcher.BeginInvoke=0;
Request.Phase.RequestDispatcher.Complete=31;
Request.Phase.PostQuery=0;
Request.CPU.Total=15;

Diese Daten können mit geeigneten Skripten natürlich auch ausgewertet werden.

Weitere Links