TsgcWSServer_HTTPAPI expõe uma propriedade published chamada FineTune do tipo TsgcServerHTTPAPI_FineTune. Ela agrupa os ajustes de baixo nível em modo kernel que influenciam como a Windows HTTP Server API (http.sys) enfileira, despacha e completa as requisições.
Encapsula a configuração de kernel HttpServerQueueLengthProperty. Controla o número máximo de requisições pendentes que o http.sys manterá em sua queue de modo kernel antes que o servidor as tenha retirado da fila. Quando a queue está cheia, o kernel responde a novas conexões diretamente com 503 Service Unavailable, sem nunca chegar ao modo usuário.
Type: ULONG.
Padrão: 1000 (o padrão do kernel do Windows).
Range: até 65535 requisições.
O que melhora: aumentar este valor impede que o kernel rejeite tráfego legítimo em cargas de trabalho com picos (bursty) - frotas IoT reconectando após uma falha de rede, clientes de broadcast de dados de mercado reconectando após um reset do provedor ou workers de jobs agendados que conectam todos em um tick de cron compartilhado.
Quando definido como True, o servidor chama SetFileCompletionNotificationModes no handle da fila de requisições com as flags FILE_SKIP_COMPLETION_PORT_ON_SUCCESS e FILE_SKIP_SET_EVENT_ON_HANDLE. Operações de I/O sobrepostas na fila de requisições que completam de forma síncrona não postam mais um pacote de conclusão extra à I/O completion port.
Type: Boolean.
Default: False (nenhuma flag é definida, preservando o comportamento atual).
O que isso melhora: elimina um salto de modo kernel para modo usuário no caminho crítico de requisições quando a chamada retorna NO_ERROR de forma síncrona, o worker despacha a conclusão inline na thread chamadora em vez de aguardar um pacote IOCP. Este é o padrão usado pelo exemplo de referência HTTP Server High Performance da Microsoft. O flag deve ser combinado com OperatingMode = ompHighPerf.
A API é resolvida em tempo de execução via GetProcAddress a partir de kernel32. No Windows XP e anteriores (target de runtime do Delphi 7), o ponto de entrada não existe - o wrapper retorna False e o servidor é executado sem a flag definida.
Seleciona uma de duas arquiteturas de accept/dispatch.
Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).
Padrão: ompClassic.
HttpReceiveHttpRequest de forma síncrona e despacha manualmente cada requisição para o pool de workers IOCP por meio de PostQueuedCompletionStatus. Este é o comportamento histórico.ThreadPoolSize x HighPerfAcceptsPerWorker recebimentos assíncronos no IOCP vinculado à fila (padrão 32 x 4 = 128 recebimentos pendentes concorrentes). Cada worker atende sua conclusão inline e re-posta outro recebimento assíncrono, mantendo uma janela deslizante até o desligamento.
O que melhora: O ompHighPerf compensa quando o servidor enfrenta pipelines profundos de stream único (uploads/downloads de frames grandes) ou muitos clientes simultâneos (centenas a milhares). A janela de recebimento pré-postada absorve bursts sem alocação por conexão, e o dispatch inline remove o gargalo de hand-off do acceptor. Mantenha o ompClassic padrão para APIs de baixo tráfego e ambientes de desenvolvimento — em cargas leves, o overhead de manter 128 contextos pré-postados custa mais do que economiza. O modo só pode ser alterado antes de o servidor ser ativado.
Controla quantos recebimentos assíncronos cada worker IOCP pré-posta quando OperatingMode = ompHighPerf. O valor é ignorado no modo ompClassic. O número total de recebimentos pendentes simultâneos que o servidor mantém é igual a ThreadPoolSize x HighPerfAcceptsPerWorker.
Type: Integer.
Default: 4.
O que isso melhora: uma janela mais profunda por worker permite que o servidor absorva rajadas maiores de requisições de entrada sem alocar novos contextos no caminho crítico. Aumente esse valor para implantações de alta concorrência (frotas de IoT, distribuição de dados de mercado, brokers de fan-out); o custo é a memória, cada recebimento pré-postado mantém um buffer de requisição (~16 KB) reservado até ser concluído. O valor padrão 4 é um meio-termo conservador validado com base no exemplo HP do MSDN.
O trecho a seguir configura um servidor HTTP.sys para um backend IoT de alta concorrência: uma grande fila de kernel para absorver tempestades de reconexão, dispatch HighPerf com uma janela de recebimento pré-postada ampliada, e dispatch de conclusão inline habilitado.
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;
Para uma API interna típica ou de baixo tráfego, deixe cada propriedade FineTune em seu padrão:
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;