Límites de recursos para contenedores de navegador: método práctico

Los límites del contenedor responden a una pregunta operativa: ¿cuánta CPU y memoria puede consumir esta carga de navegador? No indican si el navegador es privado, si dos sesiones pertenecen a personas distintas ni si una página se comportará igual en todos los hosts. Un plan útil mantiene separadas esas preguntas.

BotBrowser puede repetir una carga autorizada en un perfil, versión, ruta y plataforma declarados y comparar resultados visibles bajo presupuestos documentados. No puede asignar capacidad del host, garantizar rendimiento, debilitar el aislamiento del navegador ni inferir la identidad de una persona por su comportamiento de recursos.

Define la carga antes de elegir límites

Empieza con una carga declarada, no con un tamaño preferido. Registra la versión del navegador, la clase de perfil, la ruta propia de prueba, los pasos de navegación, el resultado esperado, la concurrencia, la política de almacenamiento y si hay gráficos o medios. Una página de texto y una página con muchos gráficos pueden tener curvas de memoria diferentes con la misma imagen.

Mantén acotada la observación. Registra solo lo necesario para decidir: inicio, finalización, presión de CPU, presión de memoria, demora de cola y recuperación después de cerrar un worker. Una observación de recursos no es una conclusión de huella. No guardes volcados brutos si una decisión de aprobado/fallido y un presupuesto declarado son suficientes.

Usa una tabla de decisión

Elige el presupuesto inicial según la carga y concurrencia reales. La tabla es una ayuda de planificación, no una garantía universal.

Señal	Primera decisión	Comprueba antes de aumentar concurrencia
Documento ligero, una o dos sesiones, finalización estable	Empieza con CPU y memoria acotadas y deja margen al host	Repite tras cambiar versión o página
Varias páginas y cola creciente	Mantén la concurrencia y mide todo el contenedor	Revisa pendiente de memoria, limitación de CPU y recuperación
Página multimedia o gráfica bajo presión repetida	Reduce admisión o separa la clase de carga	Confirma memoria compartida, gráficos y apagado ordenado
Límite de memoria antes de terminar	Detén nuevas admisiones y conserva el registro	Aumenta solo tras reproducir con datos sintéticos y otro presupuesto

La regla es: si el resultado no termina dentro del presupuesto declarado, reduce admisión o cambia la clase antes de elevar el límite. Un límite mayor puede ocultar una fuga o una cola sin límite.

Separa límites y señales del navegador

Docker y Kubernetes controlan recursos del contenedor o pod. APIs como navigator.hardwareConcurrency ofrecen una pista del entorno a la página, no una medida de la capacidad restante del contenedor. Trátalos como contexto, no como identidad. Dos contenedores con la misma pista pueden tener límites distintos y sufrir una planificación diferente.

La frontera de privacidad también importa. Una combinación estable de pistas de recursos, etiquetas de perfil, rutas y marcas de tiempo puede ser vinculable. Conserva versión, clase de carga y decisión de presupuesto; omite valores brutos e identificadores innecesarios. Revisa retención y acceso igual que el almacenamiento del navegador.

Monitoriza y recupera con intención

Observa el grupo completo: procesos del navegador, memoria compartida, buffers gráficos, pools de red y contadores de CPU y memoria del contenedor. Los números por pestaña sirven para diagnosticar, pero no son el contrato de capacidad. Registra inicio, resultado, cierre y recuperación suficiente para la siguiente tanda acotada.

Aplica acciones ordenadas: deja de admitir trabajo, termina o cancela el recorrido propio, cierra el contexto y registra el resultado. Si la presión no baja, conserva la carga mínima reproducible y detén el contenedor en vez de reintentarla sin fin.

Compara BotBrowser dentro de sus límites

Para comparar dos versiones autorizadas de BotBrowser, fija perfil, ruta, carga, límites y concurrencia. Compara resultados visibles y observaciones declaradas, con condiciones y límites. Una diferencia apoya una investigación de esa versión; no demuestra una causa del kernel, rendimiento universal ni identidad.

Registra la revisión de carga, versión, clase de perfil, presupuesto, concurrencia, resultado, incertidumbre, retención y siguiente acción. Así otro operador puede repetir la decisión sin recibir datos privados ni una receta de detector.

Fuentes

• Restricciones de recursos de Docker
• Gestión de recursos de contenedores en Kubernetes
• MDN: Navigator.hardwareConcurrency
• Funciones avanzadas de BotBrowser

Lecturas relacionadas: guía de despliegue de navegador con Docker y planificación de capacidad de BrowserContext.

Describe el recorrido con pasos que otro equipo pueda repetir y un criterio visible de finalización.

Empieza con una concurrencia pequeña y aumenta solo después de observar cierre y recuperación.

Registra la fase en la que aparece la presión: inicio, uso estable, cola o cierre.

Mantén separadas la solicitud del orquestador, el límite del contenedor y el tiempo de espera de la aplicación.

Una cola acotada protege al host y evita reintentos que aumentan el contexto retenido.

Si cambia la imagen, el perfil o la ruta, repite la comparación con la misma carga sintética.

Un resultado de un host grande no convierte en universal su capacidad.

Conserva solo las medidas gruesas que cambian la decisión de admisión.

Evita guardar texto de páginas, identificadores de cuenta y destinos completos cuando una clase de ruta basta.

Asigna un responsable para cada siguiente acción de admisión, imagen, ruta o recuperación.

Una diferencia de recursos no demuestra una causa del motor ni identifica a una persona.

Si el límite se alcanza, conserva el caso mínimo reproducible antes de cambiar el presupuesto.

La recuperación después de cerrar el contexto es una comprobación independiente de la finalización.

Revisa la retención cuando los valores exactos dejan de influir en la operación.

BotBrowser repite observaciones autorizadas bajo condiciones declaradas; no asigna capacidad del host.

Este contrato de operación mantiene la comparación útil sin crear un inventario innecesario de señales.