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.
Questa opzione non è supportata e impostarla non ha alcun effetto. La proprietà viene mantenuta solo per compatibilità, in modo che i moduli e il codice esistenti che la utilizzano continuino a caricarsi.
Tipo: Boolean.
Predefinito: False.
Perché non è supportata: l'I/O overlapped del server si basa su un pacchetto di completamento per ogni chiamata, anche quando la chiamata ha esito positivo immediatamente.
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 e dispatch HighPerf con una finestra di ricezione pre-inviata allargata.
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;
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;