TsgcWSServer_HTTPAPI espone una proprietà pubblicata denominata FineTune di tipo TsgcServerHTTPAPI_FineTune. Raggruppa i controlli di basso livello in modalità kernel che influenzano il modo in cui la Windows HTTP Server API (http.sys) mette in coda, distribuisce e completa le richieste.
Racchiude l'impostazione del kernel HttpServerQueueLengthProperty. Controlla il numero massimo di richieste in attesa che http.sys manterrà nella sua coda in modalità kernel prima che il server le abbia rimosse dalla coda. Quando la coda è piena, il kernel risponde alle nuove connessioni con 503 Service Unavailable direttamente, senza mai raggiungere la modalità utente.
Tipo: ULONG.
Predefinito: 1000 (il valore predefinito del kernel Windows).
Intervallo: fino a 65535 richieste.
Cosa migliora: aumentare questo valore impedisce al kernel di rifiutare il traffico legittimo su carichi di lavoro a burst - flotte IoT che si riconnettono dopo un'interruzione di rete, client di broadcast di dati di mercato che si riconnettono dopo un reset del provider, o worker di job pianificati che si connettono tutti su un tick cron condiviso.
Quando impostato su True, il server chiama SetFileCompletionNotificationModes sull'handle della coda delle richieste con i flag FILE_SKIP_COMPLETION_PORT_ON_SUCCESS e FILE_SKIP_SET_EVENT_ON_HANDLE. Le operazioni di I/O in modalità overlapped sulla coda delle richieste che si completano in modo sincrono non inviano più un pacchetto di completamento extra alla porta di completamento I/O.
Tipo: Boolean.
Predefinito: False (nessun flag è impostato, preservando il comportamento corrente).
Cosa migliora: elimina un passaggio da kernel a user-mode sul percorso critico delle richieste quando la chiamata restituisce NO_ERROR in modo sincrono — il worker gestisce il completamento inline sul thread chiamante anziché attendere un pacchetto IOCP. È il pattern utilizzato dal campione di riferimento HTTP Server High Performance di Microsoft. Il flag è pensato per essere abbinato a OperatingMode = ompHighPerf.
L'API viene risolta in fase di runtime tramite GetProcAddress da kernel32. Su Windows XP e versioni precedenti (target runtime Delphi 7) il punto di ingresso non esiste - il wrapper restituisce False e il server viene eseguito senza il flag impostato.
Seleziona una delle due architetture di accept/dispatch.
Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).
Predefinito: ompClassic.
HttpReceiveHttpRequest in modo sincrono e smista ogni richiesta al pool di worker IOCP tramite PostQueuedCompletionStatus. Questo è il comportamento storico.ThreadPoolSize x HighPerfAcceptsPerWorker ricezioni asincrone sull'IOCP associato alla coda (per impostazione predefinita 32 x 4 = 128 ricezioni simultanee in sospeso). Ogni worker gestisce il proprio completamento inline e pubblica nuovamente un'altra ricezione asincrona, mantenendo una finestra scorrevole fino all'arresto.
Cosa migliora: ompHighPerf conviene quando il server gestisce pipeline a stream singolo profonde (upload/download di frame di grandi dimensioni) oppure molti client concorrenti (da centinaia a migliaia). La finestra di ricezione pre-registrata assorbe i picchi senza allocazioni per connessione, e il dispatch inline elimina il collo di bottiglia del passaggio all'acceptor. Lasciare il valore predefinito ompClassic per API a basso traffico e ambienti di sviluppo — su carichi leggeri il costo di gestire 128 contesti pre-registrati supera il risparmio. La modalità può essere cambiata solo prima dell'attivazione del server.
Controlla quante ricezioni asincrone ogni worker IOCP pre-pubblica quando OperatingMode = ompHighPerf. Il valore viene ignorato in modalità ompClassic. Il numero totale di ricezioni in sospeso concorrenti che il server mantiene è pari a ThreadPoolSize x HighPerfAcceptsPerWorker.
Type: Integer.
Predefinito: 4.
Cosa migliora: una finestra per-worker più ampia consente al server di assorbire picchi maggiori di richieste in entrata senza allocare nuovi contesti sul percorso critico. Aumentarla per distribuzioni ad alta concorrenza (flotte IoT, distribuzione di dati di mercato, broker fan-out); il compromesso è la memoria - ogni ricezione pre-inviata mantiene un buffer di richiesta (~16 KB) riservato fino al completamento. Il valore predefinito 4 è un punto di equilibrio conservativo validato rispetto al campione HP di MSDN.
Il seguente snippet configura un server HTTP.sys per un backend IoT ad alta concorrenza: una grande coda kernel per assorbire le tempeste di riconnessione, dispatch HighPerf con una finestra di ricezione pre-inviata allargata e dispatch con completamento inline abilitato.
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;
Per una tipica API interna o a basso traffico, lasci ogni proprietà FineTune al suo valore predefinito:
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;