Escalar contextos con perfiles Per-Context

La capacidad empieza por el trabajo

La capacidad de un navegador depende del trabajo y del host. Una navegación sencilla, una aplicación multimedia, un generador de documentos y un panel de larga duración consumen recursos de forma diferente. Una cifra tomada de otro despliegue carece de valor si no coinciden las páginas, acciones, red, gráficos, almacenamiento y criterios de finalización.

Los perfiles Per-Context mantienen separadas las asignaciones de perfil, almacenamiento, región y ruta de sesiones autorizadas mientras comparten determinados recursos del navegador. Esto puede reducir trabajo repetido, pero las páginas, medios, descargas, workers y capturas siguen consumiendo CPU, memoria, red y descriptores.

Planifica a partir de mediciones, no de una promesa de contextos. Define un trabajo representativo, ejecútalo en la imagen objetivo, observa el uso estable y máximo, y fija un límite con margen de recuperación. Repite el proceso al cambiar navegador, host, páginas o políticas.

Elegir el límite de aislamiento

Decide primero qué debe quedar aislado. Un contexto puede tener una partición de almacenamiento y una asignación de identidad propias dentro de infraestructura compartida. Es adecuado para tenants de prueba, verificaciones regionales y cuentas independientes cuando el propietario del servicio autoriza el trabajo.

Un contexto no es un proceso independiente del sistema operativo. Usa instancias separadas cuando se requieran privilegios, recursos, extensiones o dominios de fallo distintos. Usa hosts o contenedores separados cuando el límite incluya sistema operativo y espacio de red.

Escribe esta decisión en la política del servicio. El planificador debe saber qué trabajo puede compartir navegador y cuál requiere recursos dedicados. La presión de capacidad nunca debe rebajar un requisito de aislamiento aprobado.

Cada contexto conserva una sola asignación durante su vida. Vincula perfil, almacenamiento, ruta, región y responsable antes de la primera página o tarea. Si cambia el plan, cierra el contexto y crea una nueva asignación.

Definir un trabajo representativo

Una prueba útil empieza con una transacción de aplicación, no con una página vacía. Selecciona páginas y acciones habituales. Incluye autenticación solo con autorización y protección adecuada de credenciales. Incluye medios, descargas, capturas, documentos o actividad de fondo cuando formen parte del servicio.

Describe llegada, navegación, trabajo, finalización y limpieza. Define duración aceptable, condición de éxito, reintentos y destino del almacenamiento. Así el planificador distingue una ejecución rápida pero incompleta de una correcta.

Usa el build, imagen, host, gráficos, extensiones y clase de red de producción. Una prueba en un portátil no aprueba límites para otro entorno. La virtualización y los contenedores también influyen en memoria, almacenamiento compartido y acceso gráfico.

La preparación debe imitar producción. Si los workers permanecen calientes, mide inicio y estado caliente. Si se crea un navegador nuevo por grupo, incluye inicio y cierre. Caché y almacenamiento siguen la misma política real.

Separa clases de trabajo. Una consulta ligera y un informe con renderizado intensivo no deben compartir un coste medio. El planificador puede usar colas y límites distintos.

Incluye también los recorridos que terminan con rechazo, cancelación o espera agotada. Su limpieza puede costar más que la ruta satisfactoria. Si la medición solo representa el caso ideal, el límite aprobado perderá margen precisamente cuando la aplicación tenga más incidencias.

Asigna un propietario a cada clase. Esa persona decide qué cambio obliga a repetir la prueba, qué degradación bloquea una versión y cuándo una tarea debe pasar a infraestructura dedicada. El historial de decisiones evita comparar cifras obtenidas con condiciones diferentes.

Medir todo el ciclo de vida

Observa inicio del navegador, creación del contexto, actividad, periodos inactivos, cierre del contexto y apagado. Los picos pueden aparecer durante navegación, decodificación, capturas o limpieza. Medir solo el estado estable oculta el verdadero límite.

Registra memoria disponible, CPU, almacenamiento, red, archivos abiertos, duración, espera en cola, éxito, tiempo de creación y tiempo de cierre. Son señales operativas que indican si el servicio completa trabajo autorizado con margen de recuperación.

Mide trabajos terminados por periodo, no solo contextos simultáneos. Más concurrencia puede reducir el rendimiento por competencia de recursos. El punto adecuado completa el trabajo de forma previsible dentro de los objetivos del servicio.

Incluye la limpieza tras fallos. Cancela un trabajo en puntos controlados, activa la ruta normal de timeout y confirma que páginas, contextos, almacenamiento y leases se liberan.

Ejecuta la prueba durante tiempo suficiente para detectar acumulación. Observa memoria residual y evolución del cierre. Investiga tendencias antes de aumentar límites.

Repite una parte de la medición después de periodos inactivos y de actividad sostenida. Algunos servicios mantienen recursos mientras esperan y otros los recuperan al cerrar una tarea. Ambas fases forman parte del coste real y deben quedar reflejadas en el informe de capacidad.

Fijar un límite seguro

Aumenta la carga por pasos y mantén cada nivel hasta lograr un patrón estable. Compara trabajo completado, latencia, errores y margen con el paso anterior. Detente cuando empeoren los objetivos o disminuya demasiado el margen. El límite aprobado debe quedar por debajo.

Reserva capacidad para variaciones de páginas, red, medios y otros servicios. El máximo que pasó una vez no es un límite operativo. Define también un umbral de emergencia que detenga la admisión antes de que el host deje de responder.

Documenta versión, imagen, host, trabajos representativos, periodo, red y fecha. Una cifra aislada pierde significado después de cualquier cambio.

Registra también la distribución de duraciones y no solo un promedio. Un grupo puede mantener una media aceptable mientras unas pocas tareas ocupan recursos durante demasiado tiempo. Revisa esos casos antes de elevar la admisión, porque pueden convertirse en una cola persistente bajo carga normal.

Aplica límites al grupo de navegador y al host. El primero controla contextos según la carga medida. El segundo controla grupos según recursos y aislamiento. Cualquiera puede activar contrapresión.

Revisa después de actualizaciones de navegador, sistema, gráficos, extensiones, páginas, almacenamiento, red o host.

La aprobación debe indicar tanto el límite normal como la acción al perder margen. Puede reducirse la admisión, desviar una clase a otro grupo o drenar el host. Una cifra sin respuesta operativa no protege al servicio durante una variación real.

Aplicar contrapresión al admitir

Una cola ilimitada oculta la sobrecarga. Limita su edad y el trabajo aceptado. Rechaza o aplaza solicitudes que no puedan empezar dentro del plazo acordado.

Asigna un lease a cada trabajo admitido. Vincúlalo con grupo, contexto, propietario y fecha límite. Libéralo solo al terminar la limpieza. Su caducidad permite recuperar asignaciones cuando desaparece un worker.

Considera la clase del trabajo. Las tareas costosas pueden usar un pool o peso propio. Evita que una clase bloquee permanentemente a otra.

Ritma la creación. La inicialización puede generar un pico aunque el estado estable quepa. Pausa admisión cuando aumenten la latencia de inicio o la presión de memoria.

Los reintentos obedecen los mismos límites. Usa intentos acotados, espera y un estado final. Conserva la asignación cuando la sesión autorizada deba continuar y crea otra solo por política.

Informa al productor cuando una solicitud se aplaza o se rechaza. La respuesta debe distinguir falta temporal de capacidad, vencimiento en cola y cancelación de la aplicación. Esta diferencia permite decidir si conviene esperar, reducir el lote o corregir el trabajo, sin generar una serie de reintentos.

Mantener propiedad del ciclo de vida

Un servicio debe poseer cada grupo desde el inicio hasta el cierre. Crea el navegador, admite contextos, sigue leases, cierra trabajo, drena para mantenimiento y apaga. La propiedad repartida deja recursos fuera de la visión del planificador.

Define estados como pendiente, iniciando, activo, cerrando y cerrado. Las transiciones deben tolerar repeticiones. Un contexto que no cierre a tiempo pasa a reconciliación y deja de recibir trabajo.

Espera al cierre antes de liberar el slot. Si no termina dentro del plazo medido, drena y sustituye el grupo según la política. No sigas admitiendo en un grupo con propiedad incierta.

Drena antes de actualizar. Detén admisión, deja terminar trabajos activos, cancela según política y confirma los leases. Después sustituye el grupo.

Fija una vida máxima basada en estabilidad y mantenimiento, pero no interrumpas sesiones válidas por tiempo arbitrario. Drena en un límite de sesión.

Proteger perfil y almacenamiento

El planificador asigna únicamente perfiles aprobados para trabajo, versión y región. No sustituye por otro sin relación cuando el solicitado no está disponible.

El almacenamiento persistente permanece ligado a una identidad. El efímero se elimina según política. No montes una ubicación en dos contextos activos ni unas almacenamiento antiguo a una asignación nueva.

Las rutas siguen el mismo modelo. Vincula la política antes de iniciar. Los reintentos permanecen dentro de la red autorizada. Un cambio regional requiere una sesión nueva.

Mantén credenciales fuera de perfiles y registros. Los workers reciben el acceso mínimo. Los paneles de capacidad necesitan recursos y ciclos de vida, no contenido privado.

Vigilar la salud del servicio

Controla edad de cola, trabajos admitidos y activos, finalizaciones, fallos operativos, reintentos, cancelación, cierre, sustituciones, margen de memoria, presión de CPU y hosts disponibles.

Alerta sobre tendencias. El crecimiento sostenido del tiempo de cierre, la cola o la memoria residual aporta más que un pico corto. Cada alerta debe indicar cuándo pausar, drenar, retirar un host o revertir.

Distingue fallos de aplicación y capacidad. Una validación de página puede fallar con recursos libres. La presión puede afectar varios trabajos sanos. Las categorías evitan respuestas equivocadas.

Usa referencias estables de trabajo, contexto, grupo y host, sin contenidos, credenciales ni paquetes. Recoge diagnóstico profundo solo cuando sea necesario y con retención corta.

Compara periódicamente leases con contextos activos y reconcilia diferencias mediante el cierre admitido.

Los paneles deben mostrar la clase y el estado de ciclo de vida, no solo un total agregado. Un número estable puede ocultar una cola antigua, cierres cada vez más lentos o una sola clase ocupando toda la capacidad. Relacionar tendencia y estado ofrece una señal más útil para la guardia operativa.

Recuperarse de una sobrecarga

La primera respuesta es detener la admisión. Conserva trabajos activos dentro de plazo y cancela los demás según política. Seguir creando trabajo agrava la limpieza.

Drena el grupo afectado. Si empeora el host, retíralo del planificador y deja que el supervisor sustituya sus grupos. Usa decisiones acotadas y repetibles.

Tras recuperarse, empieza por debajo del límite, confirma la limpieza y observa tendencias. Si el evento siguió a un cambio, repite la prueba antes de volver a la capacidad normal.

Si la misma condición vuelve a aparecer, mantén el grupo fuera de rotación hasta revisar su clase de trabajo, sus plazos y su imagen. Aumentar capacidad o acortar la observación sin corregir la causa operativa solo desplaza el incidente al siguiente grupo.

Conserva cronología, métricas, cola, eventos, versión y clase de trabajo. No retengas datos privados de página para explicar un incidente de capacidad.

La recuperación termina cuando el servicio vuelve a completar trabajo representativo con margen y limpieza estable. La simple disponibilidad del host no basta. Mantén reducida la admisión durante la observación y registra quién autorizó la vuelta al límite normal.

Vincula la revisión con la versión, la imagen, la clase de trabajo y el grupo afectado. Conserva el resultado anterior, la acción de recuperación y una ejecución posterior comparable. Esta secuencia permite confirmar que el servicio recuperó su ciclo completo y evita cerrar el incidente solo porque la cola empezó a avanzar.

Versiones y reversión

Incluye capacidad en la aceptación de versiones. Compara finalización, latencia, margen, creación y limpieza con la referencia. Investiga cambios materiales antes de promover.

Despliega primero en un grupo limitado y conserva la imagen anterior. Para revertir, drena el grupo candidato y restaura la pareja completa. No cambies binarios bajo contextos activos.

Registra evidencia, revisor, límite, clases afectadas y umbral de reversión. Aumentar sin datos convierte una regresión pequeña en un incidente del host.

Revisión práctica

Antes de producción, confirma:

• Cada clase tiene un trabajo representativo y una condición de finalización.
• La política define contexto, instancia o host como límite.
• La capacidad se midió en la versión, imagen y host objetivo.
• El límite conserva margen de recuperación.
• Admisión, cola, reintentos e inicio están acotados.
• Cada contexto tiene perfil, almacenamiento, ruta, responsable y ciclo de vida.
• La limpieza termina antes de devolver capacidad.
• El almacenamiento persistente no cruza identidades.
• Los paneles omiten secretos y datos privados.
• Los grupos pueden drenar y revertir sin afectar trabajo ajeno.

Durante la operación, revisa rendimiento, espera, limpieza, sustituciones y margen. Reduce admisión e investiga antes de ampliar capacidad.

Seleccionar el modelo

Per-Context sirve cuando se necesita separar identidad y almacenamiento y se permite compartir infraestructura. Las instancias separadas sirven cuando importan los límites de proceso. Los workers dedicados sirven cuando el límite incluye sistema operativo o red.

Un servicio puede combinar modelos según el trabajo. Mantén la elección en la política del planificador. Consulta la documentación Per-Context, la guía de rendimiento y la gestión de perfiles. Revisa los planes para elegir el despliegue.