HTTP.SYS High Performance Tuning

· Fonctionnalités

À partir de sgcWebSockets 2026.5.0, le composant TsgcWSServer_HTTPAPI expose une nouvelle propriété publiée, FineTune, de type TsgcServerHTTPAPI_FineTune. Elle regroupe tous les paramètres bas niveau du mode kernel qui influencent la façon dont l'API HTTP Server de Windows (http.sys) met en file, dispatche et termine les requêtes. Jusqu'à présent, ces paramètres n'existaient pas sur le composant ou étaient codés en dur — ils sont désormais publiés, persistés avec la fiche et réglables au moment du design.

La propriété FineTune est un conteneur TPersistent avec quatre sous-propriétés : QueueLength, SkipIOCPOnSuccess, OperatingMode et HighPerfAcceptsPerWorker. Chacune a une valeur par défaut qui préserve le comportement existant : la migration vers 2026.5.0 ne demande donc aucun changement de code ; tu actives chaque réglage individuellement quand une charge de travail spécifique l'exige.

Les propriétés FineTune

QueueLength : ULONG (1000 par défaut)

Ce qu'elle fait. Encapsule le réglage kernel HttpServerQueueLengthProperty. Elle contrôle le nombre de requêtes en attente que http.sys conserve dans sa file kernel avant que le serveur ne les ait dépilées. Lorsque la file est pleine, le kernel répond directement aux nouvelles connexions par 503 Service Unavailable, sans atteindre l'espace utilisateur.

Ce qu'elle améliore. Sur des charges en rafales — des milliers d'appareils IoT qui se reconnectent après une coupure réseau, des déploiements de flotte, des pics de trafic à l'ouverture des marchés — augmenter QueueLength empêche le kernel de rejeter des clients avant que ton processus ne les voie, ce qui évite les retries clients en cascade. La valeur par défaut 1000 correspond à la valeur par défaut du kernel Windows et est conservatrice pour les charges modernes ; la plage valide va jusqu'à 65535.

SkipIOCPOnSuccess : Boolean (False par défaut)

Ce qu'elle fait. Quand elle vaut True, active les drapeaux FILE_SKIP_COMPLETION_PORT_ON_SUCCESS et FILE_SKIP_SET_EVENT_ON_HANDLE sur le handle de la file de requêtes via SetFileCompletionNotificationModes. Le kernel saute alors l'envoi d'un paquet de complétion vers l'IOCP lorsqu'une opération d'E/S superposée se termine de façon synchrone.

Ce qu'elle améliore. Élimine un aller-retour kernel-vers-mode-utilisateur sur le chemin chaud de la requête lorsque l'appel renvoie NO_ERROR de façon synchrone — le worker dispatche la complétion en ligne sur le thread appelant au lieu d'attendre un paquet IOCP. C'est le pattern utilisé par l'exemple de référence Microsoft « HTTP Server High Performance ». La valeur par défaut False est délibérée : activer ce drapeau exige une gestion côté appelant des complétions en ligne. Cette propriété est destinée à être couplée à OperatingMode = ompHighPerf sur les charges où le gain de débit justifie le chemin de code supplémentaire.

OperatingMode : TsgcHTTPAPIOperatingMode (ompClassic par défaut)

Ce qu'elle fait. Sélectionne l'une des deux architectures accept/dispatch :

Ce qu'elle améliore. ompHighPerf est rentable lorsque le serveur voit soit des pipelines profonds sur un seul flux (uploads/downloads à grosses frames), soit beaucoup de clients simultanés (des centaines à des milliers). La fenêtre de réception pré-postée absorbe les rafales sans allocation par connexion, et le dispatch en ligne supprime le goulet d'étranglement du hand-off de l'accepteur. Garde ompClassic par défaut pour les API à faible trafic et les environnements de développement — sur les charges légères, le surcoût de maintenir 128 contextes pré-postés coûte plus qu'il n'économise. Le mode ne peut être changé qu'à la construction ; mélanger les modes pendant la durée de vie d'un seul processus n'est pas pris en charge.

HighPerfAcceptsPerWorker : Integer (4 par défaut)

Ce qu'elle fait. Contrôle le nombre de réceptions asynchrones que chaque worker IOCP pré-poste lorsque OperatingMode = ompHighPerf. La valeur est ignorée en mode ompClassic. Le nombre total de réceptions simultanées en attente que le serveur maintient est égal à ThreadPoolSize × HighPerfAcceptsPerWorker.

Ce qu'elle améliore. Une fenêtre plus profonde par worker permet au serveur d'absorber de plus grandes rafales de requêtes entrantes sans allouer de nouveaux contextes sur le chemin chaud. Augmente-la pour les déploiements à forte concurrence (flottes IoT, distribution de données de marché, brokers fan-out) ; le compromis est la mémoire — chaque réception pré-postée réserve un buffer de requête (~16 Ko) jusqu'à sa complétion. La valeur par défaut 4 est un compromis conservateur validé contre l'exemple MSDN « HP ».

Exemple d'utilisation

L'extrait suivant configure un serveur HTTP.sys pour un backend IoT à forte concurrence : une grande file kernel pour absorber les tempêtes de reconnexion, le dispatch HighPerf avec une fenêtre de réception pré-postée élargie, et le dispatch par complétion en ligne activé.

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;

Pour une API interne typique ou à faible trafic, laisse chaque propriété FineTune à sa valeur par défaut :

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