HTTP.SYS High Performance Tuning

· Funktionen

Ab sgcWebSockets 2026.5.0 stellt die Komponente TsgcWSServer_HTTPAPI eine neue published Eigenschaft bereit: FineTune vom Typ TsgcServerHTTPAPI_FineTune. Sie bündelt alle Low-Level-Kernel-Mode-Stellschrauben, die beeinflussen, wie die Windows HTTP Server API (http.sys) Anfragen einreiht, verteilt und abschließt. Bisher existierten diese Stellschrauben entweder gar nicht in der Komponente oder waren fest verdrahtet — jetzt sind sie published, werden mit dem Formular persistiert und können zur Entwurfszeit eingestellt werden.

Die FineTune-Eigenschaft ist ein TPersistent-Container mit vier Unter-Eigenschaften: QueueLength, SkipIOCPOnSuccess, OperatingMode und HighPerfAcceptsPerWorker. Jede hat einen Standardwert, der das bisherige Verhalten erhält, sodass der Wechsel auf 2026.5.0 keinerlei Code-Änderungen erfordert; du aktivierst jede Optimierung einzeln, wenn ein konkreter Workload das verlangt.

Die FineTune-Eigenschaften

QueueLength : ULONG (Standard 1000)

Was sie macht. Kapselt die Kernel-Einstellung HttpServerQueueLengthProperty. Sie steuert, wie viele wartende Anfragen http.sys in seiner Kernel-Mode-Queue hält, bis der Server sie abgeholt hat. Ist die Queue voll, beantwortet der Kernel neue Verbindungen direkt mit 503 Service Unavailable, ohne dass sie überhaupt den User-Mode erreichen.

Was sie verbessert. Bei stoßweisen Workloads — tausende IoT-Geräte, die nach einem Netzwerkaussetzer wieder verbinden, Flotten-Rollouts, Markteröffnungs-Spitzen — verhindert ein höherer QueueLength-Wert, dass der Kernel Clients abweist, bevor dein Prozess sie sieht. So vermeidest du kaskadierende Client-Wiederholungen. Der Standard 1000 entspricht dem Windows-Kernel-Default und ist für moderne Workloads konservativ; der gültige Bereich geht bis 65535.

SkipIOCPOnSuccess : Boolean (Standard False)

Was sie macht. Auf True gesetzt, aktiviert sie über SetFileCompletionNotificationModes die Flags FILE_SKIP_COMPLETION_PORT_ON_SUCCESS und FILE_SKIP_SET_EVENT_ON_HANDLE auf dem Request-Queue-Handle. Der Kernel verzichtet dann darauf, ein Completion-Paket an den IOCP zu posten, wenn ein überlappter I/O-Vorgang synchron abschließt.

Was sie verbessert. Entfernt einen Kernel-zu-User-Mode-Sprung auf dem heißen Request-Pfad, wenn der Aufruf synchron mit NO_ERROR zurückkehrt — der Worker dispatcht die Completion inline auf dem aufrufenden Thread, statt auf ein IOCP-Paket zu warten. Genau dieses Muster verwendet Microsofts Referenz-Sample "HTTP Server High Performance". Der Default False ist Absicht: das Flag erfordert callerseitiges Handling von Inline-Completions. Die Eigenschaft ist dafür gedacht, mit OperatingMode = ompHighPerf kombiniert zu werden, wenn der Durchsatzgewinn den zusätzlichen Code-Pfad rechtfertigt.

OperatingMode : TsgcHTTPAPIOperatingMode (Standard ompClassic)

Was sie macht. Wählt zwischen zwei Accept/Dispatch-Architekturen:

Was er verbessert. ompHighPerf zahlt sich aus, wenn der Server entweder tiefe Single-Stream-Pipelines (Large-Frame-Uploads/Downloads) oder viele gleichzeitige Clients (Hunderte bis Tausende) sieht. Das vorausgepostete Receive-Fenster fängt Bursts ohne Per-Connection-Allokation ab, und das Inline-Dispatch beseitigt den Acceptor-Übergabe-Flaschenhals. Für Low-Traffic-APIs und Entwicklungsumgebungen lass den Default ompClassic — bei leichten Workloads kostet das Vorhalten von 128 vorbereiteten Kontexten mehr, als es spart. Der Modus kann nur zur Konstruktionszeit gewechselt werden; das Mischen von Modi innerhalb eines Prozesslebenszyklus wird nicht unterstützt.

HighPerfAcceptsPerWorker : Integer (Standard 4)

Was sie macht. Steuert, wie viele async Receives jeder IOCP-Worker vorausposted, wenn OperatingMode = ompHighPerf ist. Im ompClassic-Modus wird der Wert ignoriert. Die Gesamtzahl der gleichzeitig offenen Receives, die der Server hält, entspricht ThreadPoolSize × HighPerfAcceptsPerWorker.

Was sie verbessert. Ein tieferes Per-Worker-Fenster lässt den Server größere Bursts eingehender Anfragen abfangen, ohne auf dem heißen Pfad neue Kontexte zu allokieren. Erhöhe ihn für hochgradig nebenläufige Deployments (IoT-Flotten, Marktdaten-Verteilung, Fan-out-Broker); der Trade-off ist Speicher — jedes vorausgepostete Receive belegt einen Request-Buffer (~16 KB), bis es abschließt. Der Default 4 ist ein konservativer Mittelweg, der gegen das MSDN-"HP"-Sample validiert wurde.

Beispiel zur Nutzung

Der folgende Ausschnitt konfiguriert einen HTTP.sys-Server für ein hochgradig nebenläufiges IoT-Backend: eine große Kernel-Queue zum Abfangen von Reconnect-Stürmen, HighPerf-Dispatch mit erweitertem vorausgepostetem Receive-Fenster und aktiviertes 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;

Für eine typische interne oder traffikarme API lass jede FineTune-Eigenschaft auf ihrem Default:

oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;