IIS7 Integrierte Pipeline: die Interaktion zwischen maxConcurrentRequestsPerCPU und requestsQueueLimit Einstellungen

Erstens gibt es eine tolle übersicht über die IIS7 HTTP-request-Lebenszyklus und die verschiedenen Einstellungen, die die Leistung beeinflussen hier:

ASP.NET Thread-Nutzung unter IIS 7.0 und 6.0

Sehr speziell aber in dotNet 4 die Standardwerte für maxConcurrentRequestsPerCPU und requestsQueueLimit eingestellt sind 5000. E. g. äquivalent zu: (in aspnet.Konfiguration):

<system.web>
   <applicationPool 
      maxConcurrentRequestsPerCPU="5000" 
      maxConcurrentThreadsPerCPU="0" 
      requestQueueLimit="5000" /> (** see note below)
</system.web>

Scheint mir, dass auf multi-CPU/core-server der requestQueueLimit hier wird immer aufgerufen werden, auch bevor die "perCPU' begrenzen. Wenn also ein Maximum von 5000 Anfragen pro CPU ist, was Sie wirklich wollen dann würde ich erwarten, dass die requestQueueLimit erhöht werden muss, um zu 5000 * CPUCount oder nur vollständig deaktiviert.

Ist meine interpretation korrekt? Wenn ja, kann ich das deaktivieren requestQueueLimit? (setzen Sie ihn auf null?). Die Dokumentation dieser Einstellung nicht angezeigt wird, um auf diese Frage einzugehen (also vielleicht bin ich etwas fehlt oder verlesen?)

** Anmerkung aus dem obigen Artikel: Die requestQueueLimit ist schlecht benannt. Tatsächlich begrenzt die maximale Anzahl von Anfragen, die bearbeitet werden können, indem ASP.NET gleichzeitig. Dies gilt sowohl für Anfragen, die sind in der Warteschlange und Anforderungen, ausgeführt werden. Wenn der "Aktuelle Anforderungen" Leistungsindikator übersteigt requestQueueLimit, neu eingehende Anträge werden abgelehnt mit der Statuscode 503)

  • Ich fragte Thomas (Autor von dem Beitrag, den Sie zeigen) zu kommentieren.
InformationsquelleAutor redcalx | 2011-01-19
  1. 12

    ***Ist meine interpretation korrekt?

    Ja, wenn Sie ausführen möchten, mehr als 5000 Anfragen gleichzeitig, müssen Sie erhöhen die requestQueueLimit. Die requestQueueLimit schränkt die Gesamtzahl der Anfragen im system. Durch sein Vermächtnis, es ist eigentlich die Gesamtzahl der Aufträge im system, und nicht die Anzahl der Anfragen, die in irgendeiner Warteschlange. Ihr Ziel ist es, zu verhindern, dass die server von Umkippen aufgrund von Mangel an physischen Speicher, virtuellen Speicher, etc. Wenn das limit erreicht ist, werden eingehende Anfragen erhalten eine schnelle 503 "Server Too Busy" - Antwort. Übrigens, die aktuelle Anzahl der Anforderungen im system verfügbar gemacht wird, durch den "ASP.NET\Aktuelle Anforderungen" performance counter.

    ***kann ich das deaktivieren requestQueueLimit? (setzen Sie ihn auf null?)

    Können Sie effektiv deaktivieren Sie es, indem Sie es auf einen großen Wert, wie 50000. Sie müssen den Wert in der aspnet.config Datei Zweifel Ihre server verarbeiten kann, 50000 gleichzeitige Anfragen, aber wenn das so ist, dann doppelt. Eine Einstellung von null wird man nicht deaktivieren...seltsam, es bedeutet nicht mehr als eine Anforderung kann parallel ausgeführt werden.

    Durch die Art und Weise, es sieht aus wie es ist ein bug in v4. Für den integrierten Modus, es werden nur erfolgreich liest den Wert des requestQueueLimit, wenn es konfiguriert ist, in der aspnet.config-Datei als beschrieben auf der MSDN-Website. Für einige Grund, v4 war nicht Lesen Sie es von der Maschine.config, wenn ich experimentierte mit es Sie ein wenig wenig vor.

    • Vielen Dank für diese. Vielleicht könnten Sie klären ein wichtiger Punkt für mich. Wenn die Anforderungen insgesamt in-progress überschreiten requestQueueLimit dann bekommt der Kunde einen "503 Server Zu Beschäftigt' - OK. Ich bekomme auch einen 503-wenn maxConcurrentRequestsPerCPU überschritten wird /vor/ requestQueueLimit? Das heißt, Sie sind sowohl gating die Anzahl der Anfragen, die mehr oder weniger an der gleichen Stelle in die request-Verarbeitung lifecycle? Was von dem, was ich gelesen habe, ist ein Erbe, wie IIS und ASP.NET entwickelt haben.
    • Werden Sie nicht bekommen, 503, wenn maxConcurrentRequestsPerCPU überschritten wird, bevor requestQueueLimit. Wenn maxConcurrentRequestsPerCPU überschritten wird, bevor requestQueueLimit, wird die Anforderung einer Warteschlange Hinzugefügt. Es wird aus der Warteschlange entfernt werden, sobald einer der Erledigung von Rechtshilfeersuchen abgeschlossen.
    • Entschuldigt aber immer noch nicht 100% klar... ich hatte den Eindruck, aus Ihrem blog, dass die CLR-ThreadPool-Warteschlange queue Anfragen, wenn maxConcurrentRequestsPerCPU * CPUCount war größer als maxWorkerThreads * CPUCount. Daher habe ich angenommen, dass der ThreadPool-Q /wurde/ die Globale Q Sie bezeichnet in Ihrem blog. Scheint, dass Sie sagen, dass es eine andere Warteschlange (legacy von IIS6?) abgesehen von der ThreadPool-Q?
    • Im integrierten Modus, Globale Warteschlange ist die native Verteilung. Von Anfang an...HTTP empfängt die Anfrage und Beiträge zu IIS CP. IIS nimmt Antrag auf CP-thread und ruft in ASP.NET. ASP ruft QUWI zu posten CLR TP, wenn requestQueueLimit nicht überschritten wird. Eine native callback (in webengine.dll) nimmt Anfrage auf CLR-worker-thread, wir vergleichen maxConcurrentRequestsPerCPU * CPUCount total aktiven Anforderungen. Wenn wir die Grenze überschritten haben, Anforderung eingefügt wird, die in der globalen Warteschlange (native code). Ansonsten wird es ausgeführt werden. Wenn es war in der Warteschlange, wird er aus der Warteschlange entfernt, wenn einer der aktiven Anforderungen abgeschlossen ist.
    • Danke Thomas, das war äußerst nützlich. Wir waren auch nur wonderign über die minFreeThreads Einstellung(en), dass ich glaube, nicht mehr gelten in der integrierten pipeline - gibt es ähnliche Einstellungen sollten wir die Einstellung oder die Möglichkeiten oder haben wir nicht zu befürchten Faden Erschöpfung? Meine Vermutung in diesem Stadium wäre, dass maxConcurrentRequestsPerCPU gesetzt werden sollten /weniger/ als maxWorkerThreads um genügend threads für processign jede Anforderung. Allerdings sind die Standardeinstellungen maxConcurrentRequestsPerCPU=5000 und maxWorkerThreads ist viel niedriger (100 oder 250 glaube ich).
    • Die minFreeThreads Einstellung gilt für classic-Modus. Die Analogie für den integrierten Modus wäre maxConcurrentThreadsPerCPU, die deaktiviert ist (d.h. hat den Wert 0) standardmäßig im integrierten Modus. Nehmen Sie bitte diese Diskussion in meinem blog, wenn Sie möchten, um fortzufahren. Die Standardeinstellungen sind für die meisten Leute, aber nicht jeder. Es hängt davon ab, was du tust. Idealerweise würden wir optimieren automatisch, aber wir sind noch nicht da.

    InformationsquelleAutor Thomas
  2. 2

    Möchten Sie vielleicht zu prüfen, diese Anwendung Quellcode. IIS-tuner ist ein open-source-Anwendung, die optimiert IIS-Einstellungen für eine bessere Leistung. Auf der anderen Seite diese Seite könnte nützlich sein für Ihre Fragen.

    InformationsquelleAutor Zuuum
Schreibe einen Kommentar