Planificación de capacidad de BrowserContext

BrowserContext permite separar el almacenamiento y el estado de sesión mientras se comparte el coste de iniciar el navegador. Cada contexto activo consume recursos. La pendiente puede cambiar después de actualizar el navegador, la imagen del anfitrión, la página o la política del perfil. La planificación de capacidad debe medir el grupo completo del navegador, en lugar de heredar un límite antiguo de contextos.

BrowserContext separa el almacenamiento y el estado de sesión dentro de una infraestructura de navegador compartida. No constituye una frontera de sistema operativo, proceso ni seguridad. Si se necesitan esas fronteras, usa un navegador o anfitrión dedicado.

BotBrowser admite Per-Context Fingerprint de ENT Tier 3, que asigna perfiles separados a varios BrowserContexts dentro de un mismo proceso del navegador (aislamiento por contexto y pruebas publicadas). Esas pruebas describen configuraciones específicas; no garantizan capacidad para otro anfitrión, carga, perfil o ciclo de vida ni establecen un número de contextos universalmente seguro. Mide el grupo completo antes de fijar límites de admisión.

Resumen

• Mide el grupo completo del navegador con la versión, el perfil, el anfitrión y la carga representativa de destino; el recuento de contextos de otra configuración no es un límite de capacidad.
• Fija la admisión en el punto operativo repetible más alto o por debajo, conservando margen para los contextos que se cierran, el trabajo del navegador y los servicios del anfitrión.
• Trata la creación, el uso estable, la inactividad, el cierre y la recuperación como fases distintas; cerrar un contexto no garantiza volver de inmediato a la línea base.
• Pausa la admisión cuando se agote el margen. Tras la recuperación o la restauración de la versión aceptada, reanúdala solo cuando confirmes que el margen ha vuelto.

Índice

• Definir la unidad de versión y la carga de trabajo
• Medir la curva de capacidad del grupo completo
• Establecer límites reversibles de admisión y cola
• Operar, recuperar y revertir
• Registrar, entregar y revalidar
• Conclusión

Definir la unidad de versión y la carga de trabajo

Preparar una carga de trabajo repetible

Elige un conjunto pequeño de cargas de trabajo que represente el servicio. Un flujo de documentos, uno de formularios, una página con uso intensivo de gráficos y una tarea en segundo plano pueden tener pendientes de memoria distintas. Usa valores sintéticos y destinos controlados. La finalidad es ejercitar el ciclo de vida de la página, no reproducir datos privados de clientes.

Pon nombre y número de revisión a cada carga de trabajo. Registra cómo empieza una sesión, qué hace, cómo termina y cuándo se cierra el contexto. La versión aceptada y la candidata deben ejecutar la misma revisión del recorrido. Si la aplicación cambió, actualiza el recorrido antes de comparar versiones del navegador.

Prepara el navegador de la misma manera en cada ejecución. Algunos despliegues crean un grupo de navegadores y después admiten contextos gradualmente. Otros crean un grupo fijo antes de abrir la primera página. Elige el patrón real y mantenlo estable. El resultado de un inicio en frío y el de un grupo preparado responden a preguntas de capacidad distintas.

Anota workloadRevision y activeContextCount en cada ejecución para comparar la candidata con la versión aceptada bajo las mismas condiciones.

Clasificar la carga antes de contar contextos

La planificación de capacidad empieza por las clases de carga de trabajo, no por una única cifra destacada. Un flujo de texto, una página con muchas imágenes, una página multimedia y un informe con uso intensivo de gráficos pueden tener curvas de memoria y latencia muy distintas. Nombra cada clase, elige un recorrido representativo y deja constancia del estado de finalización esperado.

Para cada clase, separa la creación, el uso activo, el tiempo inactivo y el cierre. La creación mide el coste de inicio. El uso activo muestra los recursos que necesita la página real. El tiempo inactivo revela el estado retenido. El cierre permite comprobar si los recursos vuelven cuando termina una sesión. Mirar solo el número de contextos activos oculta trabajo del ciclo de vida que puede dominar un servicio de larga duración.

Comparar el inicio en frío y el estado preparado

Mide un grupo de navegadores en frío y otro preparado que ya haya completado un recorrido representativo. El resultado en frío ayuda a planificar el inicio; el preparado ayuda a planificar la operación estable. Mantén iguales el navegador, el perfil, el anfitrión, el enrutamiento, el almacenamiento y la política gráfica para atribuir la diferencia al estado del ciclo de vida, no a un cambio del entorno.

Si el servicio reutiliza contextos, registra la regla de reutilización y el estado que se conserva intencionadamente. Si los cierra, registra la acción de cierre y el periodo de observación usado para confirmar la recuperación. Una regla de reutilización sin política de almacenamiento puede filtrar estado entre tareas no relacionadas; cerrar de forma demasiado frecuente puede consumir capacidad en inicios repetidos.

Registrar las condiciones del anfitrión y del contenedor

El mismo navegador y perfil pueden comportarse de forma distinta en un anfitrión mayor, un contenedor menor o un anfitrión con otra política gráfica. Anota la clase de anfitrión, los límites del contenedor, el enrutamiento, el almacenamiento, las extensiones y el modo de pantalla junto al número de contextos. Así, quien revise los datos podrá decidir si sigue siendo válido un registro de capacidad anterior. Para ver cómo la elección de compilación se relaciona con los recursos del anfitrión en Linux x64, consulta BotBrowser Trimmed en Linux x64: rendimiento medido.

Al cambiar a otra clase de anfitrión, repite las observaciones en frío y en estado preparado. No escales una recomendación con una simple operación aritmética. La sobrecarga compartida del navegador, la composición de las páginas y los tiempos del ciclo de vida pueden cambiar la forma de la curva. Un punto de operación menor, medido y con margen, es más útil que una cifra mayor sin verificar.

Medir la curva de capacidad del grupo completo

Medir el grupo completo del navegador

Empieza con un registro de versión que incluya la versión del navegador, la familia de perfiles, la clase del anfitrión, el límite del contenedor, la política de enrutamiento, la política de almacenamiento y la carga representativa. Mide el grupo antes de añadir contextos y repite la medición con varios números de contextos activos. Incluye las observaciones de creación, estado estable, inactividad y cierre.

El resultado útil no es una cifra universal, sino una curva de capacidad para la versión y la carga exactas:

• Memoria de referencia antes de crear el primer contexto.
• Memoria incremental mientras los contextos están activos.
• Latencia de creación al aumentar la concurrencia.
• Recuperación tras cerrar un contexto.
• Margen disponible en el anfitrión después de la limpieza.

Leer la curva de memoria

Mide más de dos cantidades de contextos. Una referencia y un máximo pueden ocultar un cambio brusco, una meseta o una demora de limpieza. En cada punto registra activeContextCount, groupMemory, creationLatency, closeLatency, la finalización de la página y la recuperación posterior al cierre.

La pendiente sirve cuando se mantiene razonablemente estable, pero no supongas que el crecimiento es lineal. Una página puede cargar un trabajador o un recurso multimedia después de iniciar el contexto. Una versión del navegador puede añadir un proceso compartido al cruzar un límite de recursos. El límite operativo debe dejar espacio para esos cambios y para el trabajo que ya está en curso.

Observa el grupo de navegadores en su conjunto. Las cifras por contexto pueden omitir procesos del navegador, memoria compartida, búferes gráficos, grupos de conexiones de red y la sobrecarga del anfitrión o del contenedor. La capacidad corresponde al grupo que operaciones puede pausar y vaciar realmente.

Elegir puntos de medición útiles

Elige puntos que correspondan a la decisión operativa. Un grupo pequeño muestra el comportamiento de inicio. Uno mediano refleja la cola normal. Uno mayor puede mostrar dónde cambian la latencia de creación, la presión de memoria o la limpieza. Detente antes de que el anfitrión llegue a un estado inseguro y registra por qué terminaste la medición.

La medición debe aclarar la siguiente decisión. Si el grupo está muy por debajo del límite, admite el siguiente lote acotado. Si la recuperación se ralentiza, pausa el grupo y deja que se vacíe. Si el resultado es inestable, repite el mismo punto con la versión aceptada antes de cambiar la carga de trabajo.

Contar la sobrecarga del navegador y del anfitrión

La memoria de los contextos es solo una parte del grupo. Los procesos del navegador, la memoria compartida, los búferes gráficos, los grupos de conexiones de red, los descriptores de archivo, la actividad del disco y los servicios del anfitrión también necesitan espacio. Una estimación por contexto puede parecer segura aunque el grupo del navegador ya esté cerca de su límite operativo.

Incluye en el registro los límites del anfitrión y del contenedor. Un anfitrión mayor puede admitir otro punto de operación, pero no convierte en universal un resultado ligado a una versión. Repite la curva después de ampliar el anfitrión o cambiar el límite del contenedor.

Comparar páginas ligeras y representativas

Una página ligera puede mostrar el coste de inicio de referencia. Una página representativa muestra los recursos que necesita realmente producción. Conserva ambas mediciones si el servicio admite las dos clases. No traslades a una carga multimedia o gráfica un límite alto medido con una página ligera; hace falta una medición aparte.

Para cada clase registra los mismos campos: navegador y perfil, anfitrión, enrutamiento, almacenamiento, extensiones, política gráfica, número de contextos activos, memoria, latencia, finalización, comportamiento al cerrar y recuperación. Mantén los detalles sensibles de las páginas fuera del resumen compartido, pero conserva suficiente contexto operativo para comparar las curvas.

Ejecutar las comprobaciones de aceptación

Ejecuta estas comprobaciones de aprobado o fallo en tu propio entorno y conserva un resultado registrado de cada una. Acepta una capacidad solo después de que se aprueben las comprobaciones 1, 2 y 4 a 7.

1. Línea base: con cero contextos abiertos, registra la memoria y la CPU del anfitrión y la memoria del grupo del navegador. Se aprueba si la línea base queda registrada y es repetible entre lecturas.
2. Prueba escalonada: aumenta el número de contextos activos en al menos tres pasos. Mantén cada paso con uso estable y un periodo de inactividad antes de registrar activeContextCount, groupMemory, creationLatency y el número de errores. Se aprueba si el paso se mantiene dentro de tu propio presupuesto de latencia y errores y queda margen en el anfitrión.
3. Capacidad aceptada: regístrala como el paso más alto en el que la comprobación 2 se aprueba y fija el límite de admisión en ese valor o por debajo.
4. Recuperación al cerrar: abre y cierra contextos durante N ciclos, con N suficiente para que se vea una tendencia. Se aprueba si la memoria se estabiliza cerca de la línea base y no crece de forma monótona entre ciclos. Cerrar no tiene por qué devolver toda la memoria, así que explica cualquier diferencia residual en lugar de darla por inofensiva.
5. Solicitud en cola: llena el grupo hasta su límite y envía una solicitud más. Se aprueba si se admite dentro de la espera indicada, o si se rechaza o aplaza con una señal clara que llegue al responsable del grupo.
6. Pausa y reanudación: lleva el grupo más allá de su umbral de pausa. Se aprueba si la admisión se pausa y solo se reanuda cuando el margen se recupera.
7. Repetición: repite las comprobaciones 1 a 6 tras una actualización del navegador, un refresco de perfil, un cambio de anfitrión o contenedor, una revisión de la página o un cambio del ciclo de vida.

Establecer límites reversibles de admisión y cola

Fijar un presupuesto con margen

El presupuesto debe indicar el límite normal de operación, el umbral de pausa, el umbral de recuperación y quién puede cambiarlos. Deja espacio suficiente para un contexto que se está cerrando, un proceso del navegador que se está reiniciando y los servicios del anfitrión necesarios para el despliegue.

No calcules el límite solo a partir de la memoria disponible. La CPU, los descriptores de archivo, la memoria compartida, las conexiones de red, el espacio en disco y el tiempo de respuesta de las páginas pueden convertirse antes en factores limitantes. Registra la métrica que detiene la admisión y las métricas que explican por qué se alcanzó el límite.

Observar el comportamiento de la cola

El control de admisión es más fácil de operar cuando el estado de la cola es visible. Registra el trabajo en espera, los contextos activos, el trabajo completado, queueAge del elemento más antiguo y la acción tomada al alcanzar el punto de pausa. Una cola acotada puede rechazar o aplazar trabajo nuevo mientras las sesiones activas terminan de forma segura.

No permitas que un ciclo de reintentos oculte que el grupo de navegadores está lleno. Si falla repetidamente la creación, hay que pausar o vaciar el grupo, no añadir más trabajo. Registra la acción de recuperación y ponla a disposición de quien opera el grupo.

Hacer reversible la admisión

El control de admisión necesita una persona responsable y una acción reversible. Cuando el grupo alcanza su punto operativo aprobado, pausa el trabajo nuevo o aplázalo en una cola acotada. Deja terminar los recorridos activos y observa si se recuperan la memoria y la latencia. No ocultes un grupo lleno detrás de reintentos o de una cola sin límite.

El registro de recuperación debe decir qué hizo la persona operadora, qué trabajo terminó y qué cambió cuando se vació el grupo. Si los recursos no se recuperan, conserva la referencia aceptada e investiga una clase de carga cada vez. Aumentar la concurrencia antes de entender la recuperación dificulta interpretar la siguiente medición.

Separar grupos solo cuando haga falta

Separa grupos cuando una carga tenga un límite operativo o una ruta de recuperación realmente distintos. Un flujo multimedia puede necesitar límites distintos de los de una tarea solo de texto. Un objetivo móvil puede requerir otra clase de anfitrión. Mantén pocos grupos para que quienes operan el servicio entiendan cada presupuesto.

Cada grupo necesita un nombre, una clase de carga, un par de navegador y perfil, una clase de anfitrión, políticas de enrutamiento y almacenamiento, una persona responsable de admisión, un límite aceptado, un umbral de pausa, una regla de recuperación y un paquete de reversión. Un grupo sin responsable no constituye un límite operativo.

Operar, recuperar y revertir

Cubrir las fases del ciclo de vida

La creación, el estado estable, la inactividad y el cierre tienen formas de consumo de recursos distintas. Un servicio que crea muchos contextos con rapidez puede necesitar un límite de creación aunque la memoria estable sea aceptable. Un servicio que mantiene sesiones abiertas durante horas necesita comprobar la recuperación después de un periodo largo de inactividad.

Clasifica cada observación en lifecyclePhase (creación, uso activo, inactividad o cierre) y registra recoveryResult después de vaciar el grupo.

Cierra el contexto mediante el ciclo de vida admitido y espera la señal normal de limpieza antes de abrir el siguiente grupo de prueba. Anota si la memoria vuelve al intervalo esperado. Si no lo hace, no atribuyas la diferencia a la capacidad hasta comprobar la carga de las páginas, las descargas, los medios, los trabajadores y las extensiones.

Usa el control de admisión para que la limpieza siga siendo posible. Pausar trabajo nuevo da tiempo a que terminen las sesiones activas y a que el navegador libere recursos. Si un ciclo de reintentos crea otro contexto mientras el anfitrión está bajo presión, un problema recuperable puede convertirse en una interrupción.

Operar un grupo de larga duración

Los grupos de larga duración necesitan una ventana de observación que corresponda a la duración del servicio. Vigila el número de contextos activos, la memoria del grupo y la disponible, la latencia de creación y cierre, la antigüedad de la cola, el trabajo completado y la recuperación después de vaciarla. Usa valores agregados en lugar de registrar contenido privado de las páginas.

Cuando una métrica supere el umbral de pausa, detén primero la admisión. Deja terminar las tareas seguras, vacía los contextos según la política y restaura la versión aceptada si la candidata no se recupera. Registra si el grupo vuelve a su intervalo anterior. Si no lo hace, mantenlo en pausa e investiga la carga o el anfitrión antes de promover la versión.

Revisar las decisiones de cierre y reutilización

Algunos servicios cierran un contexto después de cada tarea. Otros reutilizan uno durante una sesión controlada. Mide el ciclo de vida que usará realmente el servicio. La reutilización puede evitar el coste de inicio, pero exige una política clara de almacenamiento y sesión. El cierre puede reducir el estado retenido, pero añade trabajo de creación.

La elección correcta depende de la aplicación y de la política de privacidad. Déjala visible en el registro de capacidad. Si reutilizar un contexto cambia el estado esperado, no lo uses para trabajo no relacionado. Si un contexto cerrado no permite recuperar recursos, pausa la admisión e investiga la carga antes de aumentar la concurrencia.

Registrar, entregar y revalidar

Comparar cambios del navegador y del perfil

Una versión de mantenimiento del navegador puede cambiar la memoria, el inicio, la disposición de procesos o el comportamiento de cierre aunque la página siga viéndose bien. Una actualización del perfil puede cambiar los gráficos, el idioma, el almacenamiento o los permisos y, por tanto, la carga de la página. Separa estos cambios durante la primera comparación.

Empareja una versión del navegador con el paquete de perfiles correspondiente. Fija la clase de anfitrión, las políticas de enrutamiento y almacenamiento, las extensiones y la revisión de la carga. Mide primero el par aceptado y después el candidato. Si el candidato necesita una medida temporal, anota el motivo, el efecto medido y la condición para retirarla.

Publicar solo la parte útil

Al compartir resultados de capacidad, presenta mediciones agregadas sin detalles del anfitrión de un cliente, muestras privadas de memoria, nombres de procesos internos ni cifras que puedan confundirse con un límite universal. Mide la versión, el perfil, el anfitrión y la carga de tu propio despliegue.

Plantilla del registro de capacidad

Mantén un registro por cada versión del navegador y clase de carga de trabajo. Incluye la compilación exacta del navegador, la familia de perfiles, la plataforma de destino, la memoria del anfitrión, el límite del contenedor, las políticas de pantalla y gráficos, las políticas de enrutamiento y almacenamiento, el límite operativo aceptado, la condición de reversión y la persona responsable. Registra estas mediciones de carga y ciclo de vida:

Campo	Registro
workloadRevision	Revisión fija del recorrido usado para comparar
activeContextCount	Contextos activos a la vez en cada escalón
groupMemory	Memoria del grupo del navegador en cada punto
creationLatency	Latencia de creación de contextos en cada escalón
closeLatency	Latencia de cierre y recuperación posterior
lifecyclePhase	Creación, uso activo, inactividad o cierre
queueAge	Antigüedad de la solicitud más antigua en cola
recoveryResult	Si el grupo volvió a su rango operativo aceptado

Reabre el registro después de cualquier cambio en el navegador, anfitrión, perfil, página, extensiones, gráficos o red. La planificación de capacidad es un control continuo de versiones, no una prueba de rendimiento puntual.

Mantener la recomendación ligada a la versión

Una cifra de capacidad corresponde a una versión del navegador, una familia de perfiles, una clase de anfitrión, una carga de trabajo y una política operativa. Vuelve a comprobarla después de una actualización del navegador o del perfil, una revisión de página, una actualización de extensión, un cambio gráfico o de enrutamiento, o una modificación de la imagen del anfitrión. El registro sigue siendo útil aunque haya que revisar su límite.

La guía Scaling BrowserContexts existente cubre el aislamiento de contextos y las concesiones generales de recursos. Esta página se centra en curvas de memoria medidas, observación prolongada, admisión y recuperación. Browser Release Validation describe el proceso más amplio de promoción de candidatos.

Preparar una entrega práctica de capacidad

Antes de poner un grupo en producción, entrega el par de navegador y perfil, la clase de anfitrión, workloadRevision, el límite operativo aceptado, el umbral de pausa, la regla de recuperación y el paquete de reversión. Nombra a la persona que puede pausar la admisión. Una cola sin responsable convierte una medición en una suposición.

Indica la ventana de medición y las condiciones no probadas. Si la curva cubre un flujo de texto, pero no medios, dilo. Si la observación duró treinta minutos y el servicio funciona durante la noche, programa una observación más larga en vez de presentar el resultado breve como evidencia de larga duración.

Mantén el registro junto al proceso de publicación. Vuelve a abrirlo después de cambiar la versión principal del navegador, el perfil, la página, la imagen del anfitrión, las extensiones, la pila gráfica, el enrutamiento o el almacenamiento. Un registro pequeño y repetible evita que el servicio conserve en silencio un presupuesto de contextos obsoleto.

Si el servicio tiene varias colas, mantén un registro para cada una. Una cola de tareas de texto breves puede vaciarse pronto mientras otra de informes grandes sigue activa. Al combinarlas, una cola sana puede parecer bloqueada o una ocupada puede parecer libre. Anota la cola, la clase de carga y la persona responsable en cada revisión para que la decisión corresponda a la ruta correcta del servicio.

Cuando un grupo alcanza su límite operativo, la primera acción debe ser operativa, no especulativa: detén la admisión, deja terminar las tareas seguras y observa la recuperación. Restaura la versión aceptada si la candidata no vuelve al intervalo aprobado. Después investiga la carga con una referencia estable.

Fuentes públicas

• Optimización del rendimiento de BotBrowser: Guía de memoria del grupo y ajuste del inicio
• Aislamiento por contexto de BotBrowser: Perfiles por contexto en un solo proceso de navegador
• Metodología de benchmarks de BotBrowser: Hardware probado, compilación, método y resultados de escala y ciclo de vida por contexto
• BrowserContexts de Playwright: Aislamiento de almacenamiento, sesión y cookies de BrowserContext

Conclusión

No existe un recuento seguro de contextos que pueda trasladarse entre entornos. Acepta un límite solo después de que el grupo de destino complete la carga representativa, se mantenga dentro de sus presupuestos de latencia y recursos, y se recupere tras cerrar y drenar. Mantén reversible la admisión: pausa en el umbral registrado, reanuda después de la recuperación y repite la medición cuando cambien el navegador, el perfil, la carga, el anfitrión o el ciclo de vida. Un número de capacidad también depende de dónde se ejecuta el navegador, porque un endpoint gestionado sustituye una medida propia por un límite de sesión publicado: navegador gestionado frente a navegador autoalojado compara las dos formas de costo.