TsgcWSServer_HTTPAPI expose une propriété publiée nommée FineTune de type TsgcServerHTTPAPI_FineTune. Elle regroupe les réglages de bas niveau du noyau qui influencent la façon dont l'API serveur HTTP Windows (http.sys) met en file d'attente, distribue et complète les requêtes.
Enveloppe le paramètre noyau HttpServerQueueLengthProperty. Il contrôle le nombre maximum de requêtes en attente que http.sys conservera dans sa file d'attente en mode noyau avant que le serveur ne les ait retirées. Lorsque la file est pleine, le noyau répond aux nouvelles connexions avec 503 Service Unavailable directement, sans jamais atteindre le mode utilisateur.
Type : ULONG.
Défaut : 1000 (valeur par défaut du noyau Windows).
Plage : jusqu'à 65535 requêtes.
Ce qu'il améliore : augmenter cette valeur empêche le noyau de rejeter le trafic légitime sur les charges de travail en rafale — flottes IoT se reconnectant après une panne réseau, clients de diffusion de données de marché se reconnectant après une réinitialisation du fournisseur, ou workers de tâches planifiées qui se connectent tous sur un tick cron partagé.
Lorsque défini sur True, le serveur appelle SetFileCompletionNotificationModes sur le handle de la file de requêtes avec les indicateurs FILE_SKIP_COMPLETION_PORT_ON_SUCCESS et FILE_SKIP_SET_EVENT_ON_HANDLE. Les opérations d'E/S superposées sur la file de requêtes qui se terminent de manière synchrone ne publient plus de paquet de complétion supplémentaire sur le port d'achèvement d'E/S.
Type : Boolean.
Défaut : False (aucun indicateur n'est défini, préservant le comportement actuel).
Ce que cela améliore : élimine un saut kernel-vers-mode-utilisateur sur le chemin de requête critique lorsque l'appel retourne NO_ERROR de façon synchrone — le worker distribue l'achèvement en ligne sur le thread appelant au lieu d'attendre un paquet IOCP. C'est le modèle utilisé par l'exemple de serveur HTTP haute performance de référence de Microsoft. Ce drapeau est destiné à être associé avec OperatingMode = ompHighPerf.
L'API est résolue à l'exécution via GetProcAddress depuis kernel32. Sur Windows XP et antérieur (cible d'exécution Delphi 7), le point d'entrée n'existe pas — le wrapper renvoie False et le serveur s'exécute sans l'indicateur défini.
Sélectionne l'une des deux architectures d'acceptation/distribution.
Type : TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).
Par défaut : ompClassic.
HttpReceiveHttpRequest de façon synchrone et distribue chaque requête au pool de threads IOCP via PostQueuedCompletionStatus. Il s'agit du comportement historique.ThreadPoolSize x HighPerfAcceptsPerWorker réceptions asynchrones sur l'IOCP lié à la file d'attente (par défaut 32 x 4 = 128 réceptions en attente simultanées). Chaque worker traite sa complétion en ligne et re-poste une autre réception asynchrone, maintenant une fenêtre glissante jusqu'à l'arrêt.
Ce que cela améliore : ompHighPerf est rentable lorsque le serveur voit soit des pipelines de flux unique profonds (téléversements/téléchargements de grandes trames) soit de nombreux clients simultanés (des centaines à des milliers). La fenêtre de réception pré-postée absorbe les rafales sans allocation par connexion, et la distribution intégrée supprime le goulot d'étranglement de transfert de l'accepteur. Laissez le ompClassic par défaut pour les API à faible trafic et les environnements de développement — sur les charges de travail légères, la surcharge de maintenance de 128 contextes pré-postés coûte plus qu'elle ne rapporte. Le mode ne peut être modifié qu'avant l'activation du serveur.
Contrôle le nombre de réceptions asynchrones que chaque worker IOCP pré-publie lorsque OperatingMode = ompHighPerf. La valeur est ignorée en mode ompClassic. Le nombre total de réceptions en cours simultanées maintenues par le serveur est égal à ThreadPoolSize x HighPerfAcceptsPerWorker.
Type : Entier.
Défaut : 4.
Ce que cela améliore : une fenêtre par travailleur plus profonde permet au serveur d'absorber des rafales plus importantes de requêtes entrantes sans allouer de nouveaux contextes sur le chemin critique. Augmentez-la pour les déploiements à forte concurrence (flottes IoT, distribution de données de marché, courtiers fan-out) ; la contrepartie est la mémoire — chaque réception pré-postée réserve un tampon de requête (~16 Ko) jusqu'à son achèvement. La valeur par défaut de 4 est un juste milieu conservateur validé par rapport à l'exemple MSDN HP.
L'extrait suivant configure un serveur HTTP.sys pour un backend IoT à haute concurrence : une grande file d'attente noyau pour absorber les tempêtes de reconnexion, une distribution HighPerf avec une fenêtre de réception pré-postée élargie et une distribution à complétion intégrée activée.
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 ou à faible trafic typique, laissez 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;