TsgcWSServer_HTTPAPI stellt eine veröffentlichte Eigenschaft namens FineTune vom Typ TsgcServerHTTPAPI_FineTune bereit. Sie gruppiert die Low-Level-Kernel-Mode-Stellschrauben, die beeinflussen, wie die Windows HTTP Server API (http.sys) Anfragen einreiht, verteilt und abschließt.
Kapselt die Kernel-Einstellung HttpServerQueueLengthProperty. Sie steuert die maximale Anzahl ausstehender Anfragen, die http.sys in seiner Kernel-Modus-Warteschlange hält, bevor der Server sie aus der Warteschlange entnommen hat. Wenn die Warteschlange voll ist, antwortet der Kernel auf neue Verbindungen direkt mit 503 Service Unavailable, ohne jemals den Benutzermodus zu erreichen.
Typ: ULONG.
Default: 1000 (der Windows-Kernel-Standard).
Range: bis zu 65535 Anfragen.
Was es verbessert: Das Erhöhen dieses Werts verhindert, dass der Kernel legitimen Datenverkehr bei stoßweisen Workloads ablehnt - IoT-Flotten, die nach einem Netzwerkausfall erneut verbinden, Marktdaten-Broadcast-Clients, die nach einem Anbieter-Reset erneut verbinden, oder geplante Job-Worker, die alle zu einem gemeinsamen Cron-Tick verbinden.
Diese Option wird nicht unterstützt und ihre Einstellung hat keine Auswirkung. Die Eigenschaft wird nur aus Kompatibilitätsgründen beibehalten, damit bestehende Formulare und bestehender Code, der sie verwendet, weiterhin geladen werden.
Type: Boolean.
Standard: False.
Warum es nicht unterstützt wird: die überlappten E/A-Vorgänge des Servers verlassen sich bei jedem Aufruf auf ein Completion-Paket, selbst wenn der Aufruf sofort erfolgreich ist.
Wählt eine von zwei Accept-/Dispatch-Architekturen aus.
Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).
Standard: ompClassic.
HttpReceiveHttpRequest synchron auf und übergibt jede Anfrage über PostQueuedCompletionStatus per Hand an den IOCP-Worker-Pool. Dies ist das historische Verhalten.ThreadPoolSize x HighPerfAcceptsPerWorker asynchrone Empfangsvorgänge auf dem queue-gebundenen IOCP (standardmäßig 32 x 4 = 128 gleichzeitig ausstehende Empfangsvorgänge). Jeder Worker bedient seinen Abschluss inline und postet einen weiteren asynchronen Empfangsvorgang nach, wobei ein gleitendes Fenster bis zum Herunterfahren aufrechterhalten wird.
Was es verbessert: ompHighPerf zahlt sich aus, wenn der Server entweder tiefe Single-Stream-Pipelines (Uploads/Downloads mit großen Frames) oder viele gleichzeitige Clients (Hunderte bis Tausende) sieht. Das vorab gebuchte Empfangsfenster fängt Bursts ohne Allokation pro Verbindung ab, und der Inline-Dispatch beseitigt den Übergabe-Engpass des Acceptors. Belassen Sie den Standard ompClassic für APIs mit geringem Verkehr und Entwicklungsumgebungen — bei leichten Workloads kostet der Overhead des Verwaltens von 128 vorab gebuchten Kontexten mehr, als er einspart. Der Modus kann nur vor der Aktivierung des Servers geändert werden.
Steuert, wie viele asynchrone Empfangsvorgänge jeder IOCP-Worker vorab postet, wenn OperatingMode = ompHighPerf ist. Der Wert wird im ompClassic-Modus ignoriert. Die Gesamtzahl der gleichzeitig ausstehenden Empfangsvorgänge, die der Server aufrechterhält, entspricht ThreadPoolSize x HighPerfAcceptsPerWorker.
Type: Integer.
Standard: 4.
Was es verbessert: ein tieferes Fenster pro Worker erlaubt es dem Server, größere Bursts eingehender Anfragen aufzunehmen, ohne neue Kontexte auf dem Hot Path zu allokieren. Erhöhen Sie es für Bereitstellungen mit hoher Parallelität (IoT-Flotten, Marktdatenverteilung, Fan-out-Broker); der Kompromiss ist Arbeitsspeicher - jedes vorab abgesetzte Receive hält einen Anforderungspuffer (~16 KB), der reserviert bleibt, bis es abgeschlossen ist. Der Standardwert 4 ist ein konservativer Mittelweg, validiert anhand des MSDN-HP-Beispiels.
Der folgende Codeausschnitt konfiguriert einen HTTP.sys-Server für ein IoT-Backend mit hoher Parallelität: eine große Kernel-Queue, um Wiederverbindungsstürme abzufedern, und HighPerf-Dispatch mit einem erweiterten vorab gebuchten Empfangsfenster.
uses
sgcWebSocket_Server_HTTPAPI,
sgcWebSocket_HTTPAPI_Server; // TsgcHTTPAPIOperatingMode
var
oServer: TsgcWSServer_HTTPAPI;
begin
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := '0.0.0.0';
oServer.Port := 8080;
// absorb 10,000-device reconnect bursts before kernel-level 503
oServer.FineTune.QueueLength := 10000;
// switch from single-acceptor to pre-posted IOCP workers
oServer.FineTune.OperatingMode := ompHighPerf;
// widen the per-worker pre-posted receive window (32 threads * 8 = 256)
oServer.FineTune.HighPerfAcceptsPerWorker := 8;
oServer.Active := True;
end;
Bei einer typischen internen oder verkehrsarmen API belassen Sie jede FineTune-Eigenschaft auf ihrem Standardwert:
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;