Ajuste de alto rendimiento de HTTP.SYS

· Características

A partir de sgcWebSockets 2026.5.0, el componente TsgcWSServer_HTTPAPI expone una nueva propiedad publicada, FineTune, tipada como TsgcServerHTTPAPI_FineTune. Agrupa todos los ajustes de bajo nivel en modo kernel que influyen en cómo la Windows HTTP Server API (http.sys) encola, despacha y completa peticiones. Hasta ahora esos ajustes o no existían en el componente o estaban hardcodeados — ahora están publicados, persistidos con el formulario y son ajustables en tiempo de diseño.

La propiedad FineTune es un contenedor TPersistent con cuatro subpropiedades: QueueLength, SkipIOCPOnSuccess, OperatingMode y HighPerfAcceptsPerWorker. Cada una tiene un valor por defecto que preserva el comportamiento existente, de modo que actualizar a 2026.5.0 no requiere ningún cambio de código; te apuntas a cada ajuste de forma individual cuando una carga de trabajo específica lo demanda.

Las propiedades de FineTune

QueueLength : ULONG (predeterminado 1000)

Qué hace. Envuelve el ajuste de kernel HttpServerQueueLengthProperty. Controla cuántas peticiones pendientes mantendrá http.sys en su cola en modo kernel antes de que el servidor las haya desencolado. Cuando la cola está llena, el kernel responde a las nuevas conexiones con 503 Service Unavailable directamente, sin llegar nunca a modo usuario.

Qué mejora. En cargas de trabajo a ráfagas — miles de dispositivos IoT reconectándose tras un parpadeo de red, despliegues masivos, picos de tráfico al abrir mercado — subir QueueLength evita que el kernel rechace clientes antes de que tu proceso los vea, evitando reintentos en cascada por parte de los clientes. El valor por defecto 1000 coincide con el predeterminado del kernel de Windows y es conservador para cargas de trabajo modernas; el rango válido llega hasta 65535.

SkipIOCPOnSuccess : Boolean (predeterminado False)

Qué hace. Cuando se establece a True, activa los flags FILE_SKIP_COMPLETION_PORT_ON_SUCCESS y FILE_SKIP_SET_EVENT_ON_HANDLE en el handle de la cola de peticiones mediante SetFileCompletionNotificationModes. El kernel entonces se salta el envío de un paquete de completion al IOCP cuando una operación de E/S overlapped se completa de forma síncrona.

Qué mejora. Elimina un salto de modo kernel a modo usuario en la ruta caliente de peticiones cuando la llamada devuelve NO_ERROR de forma síncrona — el worker despacha la completion en línea en el hilo que llama en lugar de esperar un paquete IOCP. Este es el patrón que usa la muestra de referencia "HTTP Server High Performance" de Microsoft. El predeterminado False es deliberado: activar el flag requiere que el lado llamante gestione las completions en línea. La propiedad está pensada para emparejarse con OperatingMode = ompHighPerf en cargas de trabajo donde la ganancia de throughput justifica la ruta de código extra.

OperatingMode : TsgcHTTPAPIOperatingMode (predeterminado ompClassic)

Qué hace. Selecciona una de dos arquitecturas de accept/dispatch:

Qué mejora. ompHighPerf compensa cuando el servidor ve o bien pipelines profundas de un solo stream (subidas/descargas de frames grandes) o muchos clientes concurrentes (cientos o miles). La ventana de recepciones pre-publicadas absorbe ráfagas sin asignación por conexión, y el despacho en línea elimina el cuello de botella del traspaso del aceptador. Deja el predeterminado ompClassic para APIs de bajo tráfico y entornos de desarrollo — en cargas ligeras la sobrecarga de mantener 128 contextos pre-publicados cuesta más de lo que ahorra. El modo solo puede cambiarse en tiempo de construcción; mezclar modos dentro del mismo ciclo de vida del proceso no está soportado.

HighPerfAcceptsPerWorker : Integer (predeterminado 4)

Qué hace. Controla cuántas recepciones asíncronas pre-publica cada worker IOCP cuando OperatingMode = ompHighPerf. El valor se ignora en modo ompClassic. El número total de recepciones concurrentes pendientes que mantiene el servidor es igual a ThreadPoolSize × HighPerfAcceptsPerWorker.

Qué mejora. Una ventana por worker más profunda permite al servidor absorber ráfagas más grandes de peticiones entrantes sin asignar nuevos contextos en la ruta caliente. Súbelo para despliegues de alta concurrencia (flotas IoT, distribución de datos de mercado, brokers de fan-out); el compromiso es la memoria — cada recepción pre-publicada mantiene un buffer de petición (~16 KB) reservado hasta que se complete. El predeterminado 4 es un punto medio conservador validado frente a la muestra "HP" de MSDN.

Ejemplo de uso

El siguiente fragmento configura un servidor HTTP.sys para un backend IoT de alta concurrencia: una cola de kernel grande para absorber tormentas de reconexión, dispatch HighPerf con una ventana de recepciones pre-publicadas ampliada y dispatch de completion en línea activado.

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 una API típica interna o de bajo tráfico, deja cada propiedad FineTune en su valor por defecto:

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