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.
Wenn auf True gesetzt, ruft der Server SetFileCompletionNotificationModes für das Handle der Anforderungswarteschlange mit den Flags FILE_SKIP_COMPLETION_PORT_ON_SUCCESS und FILE_SKIP_SET_EVENT_ON_HANDLE auf. Überlappte E/A-Vorgänge auf der Anforderungswarteschlange, die synchron abgeschlossen werden, posten kein zusätzliches Completion-Paket mehr an den I/O-Completion-Port.
Type: Boolean.
Standard: False (es wird kein Flag gesetzt, das aktuelle Verhalten bleibt erhalten).
Was es verbessert: eliminiert einen Kernel-zu-User-Mode-Sprung auf dem Hot Request Path, wenn der Aufruf synchron NO_ERROR zurückgibt - der Worker verteilt den Abschluss inline auf dem aufrufenden Thread, anstatt auf ein IOCP-Paket zu warten. Dies ist das Muster, das vom Referenz-HTTP-Server-High-Performance-Beispiel von Microsoft verwendet wird. Das Flag ist dafür vorgesehen, mit OperatingMode = ompHighPerf kombiniert zu werden.
Die API wird zur Laufzeit über GetProcAddress aus kernel32 aufgelöst. Unter Windows XP und früher (Delphi-7-Laufzeitziel) existiert der Einsprungpunkt nicht - der Wrapper gibt False zurück und der Server läuft, ohne dass das Flag gesetzt 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, HighPerf-Dispatch mit einem erweiterten vorab gebuchten Empfangsfenster und aktiviertem Inline-Completion-Dispatch.
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;
// dispatch inline on sync-success completions; skip the IOCP round-trip
oServer.FineTune.SkipIOCPOnSuccess := True;
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;