TsgcWSServer_HTTPAPI expone una propiedad publicada llamada FineTune de tipo TsgcServerHTTPAPI_FineTune. Agrupa los controles de bajo nivel en modo kernel que influyen en cómo la API del servidor HTTP de Windows (http.sys) pone en cola, despacha y completa las solicitudes.
Encapsula la configuración del núcleo HttpServerQueueLengthProperty. Controla el número máximo de solicitudes pendientes que http.sys mantendrá en su cola en modo kernel antes de que el servidor las haya extraído. Cuando la cola está llena, el kernel responde a las nuevas conexiones directamente con 503 Service Unavailable, sin llegar nunca al modo usuario.
Tipo: ULONG.
Predeterminado: 1000 (el valor predeterminado del kernel de Windows).
Rango: hasta 65 535 solicitudes.
Qué mejora: aumentar este valor evita que el kernel rechace tráfico legítimo en cargas de trabajo con ráfagas — flotas de IoT que se reconectan tras un corte de red, clientes de difusión de datos de mercado que se reconectan tras un reinicio del proveedor, o trabajadores de tareas programadas que se conectan todos en un cron compartido.
Cuando se establece en True, el servidor llama a SetFileCompletionNotificationModes en el handle de la cola de solicitudes con los indicadores FILE_SKIP_COMPLETION_PORT_ON_SUCCESS y FILE_SKIP_SET_EVENT_ON_HANDLE. Las operaciones de E/S superpuestas en la cola de solicitudes que se completan de forma sincrónica ya no publican un paquete de finalización adicional en el puerto de finalización de E/S.
Tipo: Boolean.
Predeterminado: False (no se establece ninguna bandera, conservando el comportamiento actual).
Qué mejora: elimina un salto de modo kernel a modo usuario en la ruta de solicitudes más activa cuando la llamada devuelve NO_ERROR de forma síncrona: el trabajador despacha la finalización en línea en el hilo llamador en lugar de esperar un paquete IOCP. Este es el patrón utilizado por la muestra de referencia de Microsoft sobre alto rendimiento del servidor HTTP. El indicador está pensado para usarse junto con OperatingMode = ompHighPerf.
La API se resuelve en tiempo de ejecución mediante GetProcAddress desde kernel32. En Windows XP y versiones anteriores (destino de ejecución Delphi 7), el punto de entrada no existe: el wrapper devuelve False y el servidor se ejecuta sin el indicador establecido.
Selecciona una de dos arquitecturas de aceptación/despacho.
Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).
Predeterminado: ompClassic.
HttpReceiveHttpRequest de forma síncrona y envía manualmente cada solicitud al grupo de trabajadores IOCP mediante PostQueuedCompletionStatus. Este es el comportamiento histórico.ThreadPoolSize x HighPerfAcceptsPerWorker recepciones asíncronas en el IOCP vinculado a la cola (predeterminado 32 x 4 = 128 recepciones pendientes concurrentes). Cada trabajador procesa su finalización en línea y vuelve a publicar otra recepción asíncrona, manteniendo una ventana deslizante hasta el apagado.
Qué mejora: ompHighPerf resulta beneficioso cuando el servidor tiene pipelines de un solo flujo profundos (subidas/descargas de frames grandes) o muchos clientes concurrentes (cientos o miles). La ventana de recepción preestablecida absorbe ráfagas sin asignación por conexión, y el despacho en línea elimina el cuello de botella del traspaso al acceptor. Deje el valor predeterminado ompClassic para APIs de bajo tráfico y entornos de desarrollo: en cargas de trabajo ligeras, el coste de mantener 128 contextos preasignados es mayor que el ahorro. El modo solo puede cambiarse antes de que el servidor esté activo.
Controla cuántas recepciones asíncronas preinica cada trabajador IOCP cuando OperatingMode = ompHighPerf. El valor se ignora en el modo ompClassic. El número total de recepciones pendientes concurrentes que mantiene el servidor es igual a ThreadPoolSize x HighPerfAcceptsPerWorker.
Type: Entero.
Predeterminado: 4.
Qué mejora: una ventana más profunda por trabajador permite al servidor absorber ráfagas de solicitudes entrantes más grandes sin asignar nuevos contextos en la ruta crítica. Auméntela para implementaciones de alta concurrencia (flotas IoT, distribución de datos de mercado, brokers de difusión en abanico); la contrapartida es la memoria: cada recepción predispuesta retiene un búfer de solicitud (~16 KB) reservado hasta que se completa. El valor predeterminado 4 es un punto intermedio conservador validado con el ejemplo MSDN HP.
El siguiente fragmento configura un servidor HTTP.sys para un backend IoT de alta concurrencia: una cola de kernel amplia para absorber tormentas de reconexión, despacho HighPerf con una ventana de recepción pre-publicada ampliada y despacho de completación en línea 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 una API interna o de bajo tráfico típica, deje cada propiedad FineTune en su valor predeterminado:
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;