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.
Esta opción no es compatible y establecerla no tiene ningún efecto. La propiedad se mantiene únicamente por compatibilidad, de modo que los formularios y el código existentes que la utilizan sigan cargándose.
Tipo: Boolean.
Predeterminado: False.
Por qué no es compatible: la E/S superpuesta del servidor depende de un paquete de finalización para cada llamada, incluso cuando ésta se completa correctamente de inmediato.
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 y despacho HighPerf con una ventana de recepción pre-publicada ampliada.
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;
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;