¿Cuántas conexiones de trabajadores del proxy inverso necesitan las cargas reanudables?
No existe un número universal y seguro de conexiones de trabajadores para las cargas reanudables. Dimensiona el valor a partir de la mayor demanda simultánea de sockets que puedas reproducir y añade después un margen medido.
En un servidor doméstico, una sola carga visible puede mantener una conexión del cliente, una conexión ascendente y periodos inactivos entre fragmentos mientras el navegador reintenta o reanuda la transferencia. Empieza con los recuentos de conexiones en tiempo real durante el periodo normal de cargas más intenso, compáralos con los límites del proxy y del sistema operativo, y deja de aumentar la configuración del proxy si los descriptores de archivos, los trabajadores ascendentes, la memoria o la aplicación fallan primero.
Mide la demanda de carga en tiempo real antes de elegir un límite
Cuenta las conexiones durante la carga de trabajo relevante, no mientras el proxy está inactivo. Inicia el mismo número de cargas que probablemente ejecuten tu hogar o tu pequeño equipo, pausa y reanuda varias transferencias, e incluye cualquier cliente móvil que se vuelva a conectar después de suspenderse. Registra los sockets de cliente aceptados, los sockets ascendentes establecidos y las conexiones que esperan una respuesta ascendente.
Un límite de trabajadores lo consumen todas las conexiones abiertas gestionadas por ese trabajador, no solo las solicitudes HTTP completadas. Por eso deben incluirse en la medición las conexiones de servidor mediante proxy, junto con las conexiones de cliente.
Usa el total máximo reproducible como línea base de trabajo. Si el total solo aumenta durante oleadas de reconexiones y disminuye rápidamente, mantén ese pico separado de la demanda sostenida. Si sigue aumentando mientras el rendimiento de carga permanece estable, no consideres ese crecimiento una capacidad legítima; inspecciona la aplicación ascendente, los tiempos de espera y las sesiones estancadas antes de aumentar cualquier valor.
Convierte la demanda de sockets en capacidad por trabajador
En un proxy inverso, una carga activa suele ocupar al mismo tiempo una conexión del lado del cliente y otra del lado ascendente. HTTP keepalive, las comprobaciones de estado, las sesiones WebSocket y el tráfico administrativo consumen ranuras adicionales. Considera el doble del número de cargas simultáneas como un modelo inicial, no como una respuesta definitiva, porque el total de sockets medido es más fiable que una regla general.
Un límite visible de conexiones por trabajador puede rechazar clientes nuevos aunque las transferencias establecidas continúen. Compara el trabajador con mayor uso con su límite configurado y, después, comprueba el límite de archivos abiertos del proceso del servicio; un valor mayor en el proxy no puede crear descriptores de archivos que el proceso no tenga permitido abrir.
Elige un objetivo superior al máximo del trabajador que puedas reproducir de forma constante, con margen suficiente para el pico de reintentos observado y el tráfico habitual que no corresponda a cargas. No multipliques por todos los clientes y fragmentos posibles si esas conexiones nunca existen simultáneamente. Si el límite del sistema operativo es menor, ajusta primero esa capa o mantén el objetivo del proxy por debajo de ella.
Prueba la ruta de reanudación original e interpreta el fallo
Repite el desencadenante exacto: inicia el conjunto completo de cargas, interrumpe varios clientes y reanúdalos mientras las transferencias restantes sigan activas. Observa la aceptación de conexiones nuevas, los tiempos de reintento, el rendimiento de carga, el texto de error del proxy, el tiempo de respuesta ascendente y los descriptores de archivos abiertos. Una solicitud sintética que nunca carga un cuerpo no prueba la misma ruta de recursos.
Si el proxy informa que las conexiones de los trabajadores se han agotado justo cuando fallan las cargas nuevas, el límite es un cuello de botella confirmado. Si las solicitudes nuevas fallan por errores de tamaño del cuerpo, tiempo de espera, servicio ascendente no disponible o cola de la aplicación mientras el uso de conexiones permanece por debajo del límite, aumentar el valor de los trabajadores no solucionará el fallo. Un cálculo del límite de conexiones también debe respetar el límite de archivos abiertos y los sockets a ambos lados del proxy.
Cambia una sola capa cada vez. Aumenta el límite de trabajadores únicamente después de que los registros y las pruebas con sockets lo identifiquen como la causa, recarga el proxy y vuelve a ejecutar el mismo patrón de interrupción. Si el error pasa al servicio ascendente o al límite de descriptores de archivos, detente: has llegado a la siguiente restricción, no has demostrado que sean útiles aún más conexiones del proxy.
Mantén suficiente margen y define la condición de parada
Mantén un margen entre el trabajador con mayor uso observado y el límite configurado, pero defínelo a partir de la variación real. Un servidor pequeño con tráfico doméstico estable necesita menos reserva especulativa que un servicio público que recibe picos impredecibles. Registra la línea base, el objetivo, el número de trabajadores, el límite de archivos del proceso y el resultado máximo para poder comparar el siguiente cambio en lugar de adivinar.
La capacidad de conexiones es solo una capa de la ruta de carga. Cuando un panel funciona pero una ruta específica de sincronización o carga falla, todavía hay que aislar el endpoint y el método que fallan antes de considerar que el proxy funciona correctamente.
El cambio se considera válido cuando se completan dos pruebas completas de reanudación, las conexiones nuevas siguen siendo aceptadas, los registros de errores permanecen limpios y el trabajador con mayor uso conserva un margen estable. Revierte el aumento si la presión sobre la memoria o la latencia empeoran sin reducir los fallos. Escala el análisis a la capa de aplicación o almacenamiento cuando el uso de conexiones esté cómodamente por debajo del límite, pero las cargas sigan en cola, sufran tiempos de espera o corrompan su estado de reanudación.
Productos recomendados
Soporte y Consejos
Más para leer
Cómo programar tareas de copia de seguridad, olvido y depuración de Restic sin conflictos de bloqueo
Una programación completa de Restic para varios hosts que separa las copias de seguridad frecuentes, la retención delimitada, la depuración física, las comprobaciones, los...
Cómo evitar que los trabajos de depuración de Restic bloqueen las copias de seguridad programadas
Un plan de prevención para repositorios Restic compartidos que separe las ventanas de copia de seguridad de la poda y mantenga intactos el bloqueo,...
Cómo eliminar un bloqueo obsoleto de Restic sin interrumpir una copia de seguridad activa
Un flujo de desbloqueo de Restic mínimamente invasivo que protege las copias de seguridad activas, elimina únicamente el estado obsoleto y confirma la recuperación...
