HTTP.SYS-prestatieafstemming

· Functies

Vanaf sgcWebSockets 2026.5.0 stelt de component TsgcWSServer_HTTPAPI een nieuwe published property beschikbaar, FineTune, van het type TsgcServerHTTPAPI_FineTune. Deze groepeert elke low-level kernelmode-knop die invloed heeft op hoe de Windows HTTP Server API (http.sys) aanvragen in de wachtrij plaatst, verdeelt en afrondt. Tot nu toe bestonden die knoppen niet op de component of waren ze hardcoded — nu zijn ze published, worden ze met de form gepersisteerd en kunnen ze tijdens design time worden afgestemd.

De FineTune-property is een TPersistent-container met vier subproperties: QueueLength, SkipIOCPOnSuccess, OperatingMode en HighPerfAcceptsPerWorker. Elke property heeft een standaardwaarde die het bestaande gedrag behoudt, dus upgraden naar 2026.5.0 vereist geen enkele codewijziging; je kiest per situatie welke aanpassing je inschakelt wanneer een specifieke workload daarom vraagt.

De FineTune-properties

QueueLength : ULONG (standaard 1000)

Wat het doet. Omhult de kernelinstelling HttpServerQueueLengthProperty. Het bepaalt hoeveel openstaande aanvragen http.sys in zijn kernelmode-wachtrij vasthoudt voordat de server ze ophaalt. Wanneer de wachtrij vol is, beantwoordt de kernel nieuwe verbindingen rechtstreeks met 503 Service Unavailable, zonder de gebruikersmodus te bereiken.

Wat het verbetert. Bij piekbelastingen — duizenden IoT-apparaten die na een netwerkstoring opnieuw verbinden, vloot-uitrollen, verkeerspieken bij beursopening — voorkomt het verhogen van QueueLength dat de kernel clients weigert voordat je proces ze ziet, waardoor cascade-effecten van clientretries worden vermeden. De standaardwaarde 1000 komt overeen met de Windows-kernelstandaard en is conservatief voor moderne workloads; het geldige bereik loopt tot 65535.

SkipIOCPOnSuccess : Boolean (standaard False)

Wat het doet. Wanneer ingesteld op True worden via SetFileCompletionNotificationModes de vlaggen FILE_SKIP_COMPLETION_PORT_ON_SUCCESS en FILE_SKIP_SET_EVENT_ON_HANDLE op de handle van de aanvraagwachtrij ingeschakeld. De kernel slaat dan het posten van een completion-pakket naar de IOCP over wanneer een overlapped I/O-bewerking synchroon wordt afgerond.

Wat het verbetert. Elimineert een sprong van kernel- naar gebruikersmodus op het kritieke aanvraagpad wanneer de aanroep synchroon NO_ERROR teruggeeft — de worker handelt de completion inline af op de aanroepende thread in plaats van te wachten op een IOCP-pakket. Dit is het patroon dat Microsofts referentievoorbeeld "HTTP Server High Performance" gebruikt. De standaardwaarde False is bewust: het inschakelen van de vlag vereist dat de aanroeper inline completions verwerkt. De property is bedoeld om te worden gecombineerd met OperatingMode = ompHighPerf in workloads waarbij de doorvoerwinst het extra codepad rechtvaardigt.

OperatingMode : TsgcHTTPAPIOperatingMode (standaard ompClassic)

Wat het doet. Selecteert een van twee accept/dispatch-architecturen:

Wat het verbetert. ompHighPerf betaalt zich uit wanneer de server diepe single-stream-pipelines ziet (uploads/downloads met grote frames) of veel gelijktijdige clients (honderden tot duizenden). Het vooraf geplaatste ontvangstvenster absorbeert pieken zonder per-verbinding-allocatie, en de inline dispatch verwijdert het knelpunt van de acceptor-overdracht. Laat de standaardwaarde ompClassic staan voor API's met weinig verkeer en ontwikkelomgevingen — bij lichte workloads kost het onderhouden van 128 vooraf geplaatste contexten meer dan het oplevert. De modus kan alleen tijdens constructie worden gewijzigd; modi mengen binnen dezelfde proceslevensduur wordt niet ondersteund.

HighPerfAcceptsPerWorker : Integer (standaard 4)

Wat het doet. Bepaalt hoeveel async receives elke IOCP-worker vooraf plaatst wanneer OperatingMode = ompHighPerf. De waarde wordt genegeerd in ompClassic-modus. Het totale aantal gelijktijdig openstaande receives dat de server in stand houdt, is gelijk aan ThreadPoolSize × HighPerfAcceptsPerWorker.

Wat het verbetert. Een dieper venster per worker laat de server grotere pieken aan binnenkomende aanvragen opvangen zonder nieuwe contexten op het kritieke pad te alloceren. Verhoog deze waarde voor implementaties met hoge concurrency (IoT-vloten, distributie van marktdata, fan-out-brokers); de afweging is geheugen — elke vooraf geplaatste receive houdt een aanvraagbuffer (~16 KB) gereserveerd tot deze is voltooid. De standaardwaarde 4 is een conservatieve middenweg, gevalideerd tegen het MSDN-voorbeeld "HP".

Gebruiksvoorbeeld

Het volgende fragment configureert een HTTP.sys-server voor een IoT-backend met hoge concurrency: een grote kernelwachtrij om reconnect-stormen op te vangen, HighPerf-dispatch met een verbreed vooraf geplaatst ontvangstvenster en inline-completion-dispatch ingeschakeld.

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;
  // vang reconnect-pieken van 10.000 apparaten op voordat de kernel met 503 reageert
  oServer.FineTune.QueueLength := 10000;
  // schakel over van single-acceptor naar vooraf geplaatste IOCP-workers
  oServer.FineTune.OperatingMode := ompHighPerf;
  // verbreed het vooraf geplaatste ontvangstvenster per worker (32 threads * 8 = 256)
  oServer.FineTune.HighPerfAcceptsPerWorker := 8;
  // handel completions met synchroon succes inline af; sla de IOCP-rondreis over
  oServer.FineTune.SkipIOCPOnSuccess := True;
  oServer.Active := True;
end;

Voor een typische interne API of API met weinig verkeer laat je elke FineTune-property op de standaardwaarde staan:

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