Señales de memoria y almacenamiento en perfiles

Las aplicaciones web necesitan información de recursos para gestionar documentos grandes, contenido multimedia y tareas largas. Parte de esa información también describe la máquina host. La capacidad de almacenamiento y la clase de memoria pueden contribuir a correlacionar sesiones cuando no coinciden con el resto del perfil.

BotBrowser mantiene tres familias de recursos bajo control del perfil: cuota de almacenamiento, límite del heap de JavaScript y memoria del dispositivo. El objetivo es una identidad coherente en los hosts compatibles, no una colección de valores fijos sin relación.

Esto importa en flotas de servidores. Un perfil puede ejecutarse en una estación de trabajo, máquina virtual o contenedor mientras representa la misma familia de dispositivos. La política basada en el perfil evita que la asignación del host se convierta en la identidad predeterminada del navegador.

Por qué los recursos afectan a la privacidad

La identidad del navegador reúne propiedades relacionadas. Plataforma, familia del navegador, pantalla, procesador, memoria y almacenamiento deben describir juntos un dispositivo plausible. Cuando una propiedad refleja el servidor host y las demás siguen el perfil, la incoherencia puede facilitar la correlación de sesiones.

Los valores también pueden cambiar cuando una carga se mueve entre máquinas. Un trabajo que hoy se ejecuta en un contenedor pequeño y mañana en una estación grande no debería exponer el cambio de infraestructura si permanece activo el mismo perfil.

La coherencia es más útil que un valor universal. Un perfil móvil y uno de estación de trabajo no deben presentar la misma clase de recursos solo porque comparten un servidor. Los valores tienen que seguir la familia del perfil y permanecer estables durante el ciclo de vida previsto.

Las tres familias controladas

Cuota de almacenamiento

La cuota describe el presupuesto de almacenamiento gestionado por el navegador para el contenido web. Si depende completamente de la máquina, puede reflejar características del disco host.

En modo de perfil, BotBrowser proporciona una cuota alineada con el perfil activo en lugar del disco host. La sesión mantiene así la misma identidad de recursos cuando cambia entre sistemas compatibles.

Límite del heap de JavaScript

El límite del heap describe el presupuesto de memoria del runtime de JavaScript. Debe coincidir con la clase de dispositivo representada por el perfil. Un perfil móvil ligero y uno de escritorio con mucha memoria pertenecen a clases diferentes.

BotBrowser puede aplicar la política del perfil a nuevas sesiones y contextos. El momento del ciclo de vida importa porque el límite debe establecerse al crear el runtime.

Memoria del dispositivo

La memoria del dispositivo es una señal general de la clase de memoria. BotBrowser la alinea con el perfil activo para que la clase del dispositivo y la política del runtime no se contradigan.

Estos tres valores forman una sola descripción de recursos. Revisarlos juntos evita que un perfil presente un dispositivo de poca memoria mientras expone un presupuesto mucho mayor o una clase de almacenamiento sin relación.

Políticas de perfil, host y valores explícitos

El comportamiento basado en el perfil es la opción normal para una validación de privacidad repetible. El perfil sigue siendo la fuente de la identidad prevista aunque cambie la tarea en segundo plano.

Algunas tareas autorizadas deben seguir los recursos reales del host. Ese modo resulta adecuado cuando el host es el objeto de la prueba o cuando las pruebas de capacidad deben reflejar la tarea en segundo plano. Debe elegirse de forma deliberada porque mover el mismo perfil puede cambiar el comportamiento.

Una política explícita puede servir en pruebas controladas de compatibilidad donde una clase conocida forme parte del plan. Documéntela como configuración de prueba, no como un valor aislado del resto del perfil.

La documentación de cuota de almacenamiento contiene las opciones compatibles y las notas sobre el ciclo de vida.

Alcance de la política

Los controles documentados de BotBrowser cubren cuota de almacenamiento, límite del heap de JavaScript y memoria del dispositivo. Las tres familias deben revisarse como un grupo basado en el perfil.

Los sistemas de datos de cada origen conservan la semántica normal del navegador. Las bases de datos de la aplicación, el contenido de las cachés y la persistencia no son equivalentes a estos controles. Pruebe esas funciones como comportamiento normal del producto sin suponer que un ajuste de recursos cambia todos los subsistemas de almacenamiento.

Este límite también ayuda a diagnosticar. Una cuota incoherente pertenece a la revisión del perfil. La ausencia de datos de aplicación o un problema de caché pertenece al ciclo de almacenamiento del sitio. Separar ambas preguntas evita ampliar de forma inexacta el alcance del perfil.

Coherencia entre hosts

Una flota compartida suele contener máquinas con asignaciones diferentes. El modo de perfil ofrece una identidad de recursos común a esos workers para la misma familia de perfiles.

Admite varios patrones:

• Un perfil puede moverse entre Windows, macOS y Linux sin adoptar la clase de cada host.
• Un worker headless puede conservar la identidad prevista de una sesión con interfaz.
• Un contexto nuevo recibe la política del heap al crear su runtime.
• Un worker con varios contextos puede alinear cada uno con el perfil asignado.

La coherencia entre hosts no significa que todos los perfiles presenten los mismos valores. Significa que el perfil elegido sigue siendo la fuente de verdad en lugar de la tarea en segundo plano actual.

Decisiones de despliegue

Perfiles persistentes

Un perfil persistente debe mantener una política estable durante su ciclo de vida. Revísela antes de moverlo a otra clase de tarea en segundo plano, sobre todo si el despliegue anterior seguía deliberadamente al host.

Contextos de prueba desechables

Las pruebas cortas se benefician del modo de perfil porque un worker nuevo no cambia la identidad esperada. Cree un contexto nuevo después de modificar la política del heap.

Pruebas de capacidad y compatibilidad

Cuando una prueba mida la capacidad del host, documente esa elección por separado de la validación de privacidad. El mismo resultado no demuestra ambos objetivos porque uno sigue al worker y el otro al perfil.

Familias de dispositivos mixtas

Una flota móvil y de escritorio debe revisar cada familia por separado. Reutilizar un único ajuste puede generar incoherencias aunque el valor parezca plausible por sí solo.

Validación defensiva

Comience con la configuración y los resultados de la aplicación, sin scripts de recopilación en la página.

1. Confirme qué política de recursos espera el trabajo.
2. Confirme que el perfil previsto está activo antes de la sesión o el contexto.
3. Revise juntos cuota, heap de JavaScript y memoria del dispositivo.
4. Ejecute el flujo autorizado y observe el comportamiento funcional ante los límites.
5. Repita en otro host compatible si la versión exige coherencia entre hosts.
6. Registre la familia del perfil, el modo, la clase del host y el resultado de la aplicación.

Con varios contextos, valide cada uno después de crearlo. Una configuración correcta a nivel de proceso no demuestra que todos los contextos posteriores hayan recibido los ajustes adecuados.

En modo de perfil, el resultado esperado proviene del perfil y no del host real. El modo host tiene otro propósito y debe identificarse con claridad en los registros.

Errores comunes

Revisar cada valor por separado

Una cuota puede parecer plausible mientras el heap y la memoria describen otro dispositivo. Apruebe el grupo completo.

Cambiar la política del heap después de crear el runtime

La política pertenece al ciclo de creación. Inicie una sesión o un contexto nuevo después de un cambio.

Confundir almacenamiento de aplicación y recursos del perfil

Los datos, cachés y comportamientos de persistencia mantienen su funcionamiento normal. Pruébelos según los requisitos funcionales de la aplicación.

Permitir que un cambio de tarea en segundo plano redefina el perfil

Cuando se requiera coherencia, mantenga el modo de perfil al mover la carga. Elija el modo host solo si la prueba lo necesita.

Usar una política para familias no relacionadas

Los recursos deben coincidir con la clase seleccionada. Revise por separado las familias móviles, de escritorio y otras.

Establecer una referencia de versión

Elija tareas autorizadas que utilicen almacenamiento y memoria de forma normal, como guardar un borrador, abrir un documento grande, cargar un espacio multimedia o exportar un informe. Registre la familia de perfil, BotBrowser, la aplicación, la clase de worker, el modo de política y el resultado. Ejecute la referencia en cada clase de host prevista y mantenga separados los resultados de privacidad y de capacidad.

Mover perfiles entre clases de worker

Empiece con un grupo de prueba y confirme que la clase de destino admite la misma versión. Un despliegue basado en perfiles no debe cambiar de forma silenciosa al comportamiento del host. Detenga el worker de origen antes de iniciar el perfil persistente en el destino y valide la migración antes de ampliar el cambio.

Revisar incidentes relacionados con recursos

Clasifique primero el síntoma visible: guardado fallido, documento lento, pestaña terminada o datos sin conexión ausentes. Reproduzca la tarea con las versiones y el modo registrados. Compare la última combinación aprobada con la candidata cambiando un componente cada vez, y separe la capacidad real del host de la política del perfil.

Conservar evidencia proporcional

Use cuentas de prueba y documentos sintéticos. Guarde el resultado, las versiones y la decisión, sin conservar secretos ni historial de navegación. Asigne responsables distintos para la aplicación, el perfil y la infraestructura, porque cada uno aprueba una parte diferente del despliegue.

Revisar trabajos de larga duración

Incluya una tarea que permanezca activa el tiempo suficiente para crear datos normales de aplicación, cambiar de página y liberar recursos temporales. Confirme que el recorrido sigue siendo utilizable y que el resultado final corresponde a la familia de perfil aprobada. Registre la presión real del worker por separado de la decisión sobre la política visible del navegador.

Repita la tarea después de reiniciar el servicio y después de la limpieza normal de la aplicación. Un recorrido que solo funciona en una imagen recién creada puede indicar un problema operativo con datos retenidos. Investigue ese comportamiento sin cambiar la referencia de perfil aprobada.

Revise también una tarea que escriba y vuelva a abrir datos de prueba. La aplicación debe encontrar su propio estado cuando corresponde y eliminarlo según su ciclo de vida. Use cuentas dedicadas y contenido sintético para que el registro de versión no contenga datos personales.

Cuando el flujo incluya documentos o medios, conserva el resultado funcional junto con la observación de recursos. Un documento completo y una reproducción estable son evidencia de aplicación. El uso real de disco y memoria pertenece al presupuesto del host. No combines ambas conclusiones en un único estado ambiguo.

Gestionar el reemplazo de workers

Antes de devolver un worker nuevo al pool, instale la misma combinación aprobada de navegador, perfil, servicio y aplicación. Ejecute primero la referencia corta. El reemplazo debe completar el mismo recorrido aunque su disco físico y su asignación de memoria difieran del host anterior.

Mantenga fuera de nuevas tareas a los workers fallidos hasta revisar sus datos de aplicación. Un reemplazo no debe mover silenciosamente datos incompletos ni reutilizar un directorio desconocido. Siga la política de recuperación, retención y eliminación de la aplicación.

Registre por qué se reemplazó el host, qué combinación recibió y quién aprobó su regreso. Esta información ayuda a distinguir una sustitución ordinaria de una migración que necesita una revisión más amplia.

Si el worker pertenece a otra clase de infraestructura, trátelo como una nueva clase de despliegue. Repita las tareas representativas y el presupuesto de capacidad. La aprobación de una máquina parecida no sustituye la evidencia del destino real.

Definir decisiones de versión y reversión

Escriba la regla de aceptación antes de probar. El candidato debe completar los recorridos, conservar la política de perfil aprobada, mantenerse dentro del presupuesto del host y recuperarse después de un reinicio. Cada resultado identifica al responsable que lo aprobó.

Separe los estados de aceptar, corregir y revertir. Un resultado incompleto no debe convertirse en aprobado porque el proceso siga activo. La decisión registra qué recorrido falló y cuál fue el último punto conocido.

La reversión restaura la última combinación completa aprobada. Después, ejecuta la referencia corta y confirma que el procesamiento se ha recuperado. Conserva la evidencia del candidato para su revisión, sin mezclar componentes candidatos en el pool restaurado.

Observe la combinación restaurada durante el periodo habitual. Confirme que no quedan tareas bloqueadas, crecimiento inesperado de disco ni reinicios repetidos. Cierre el incidente cuando la aplicación y la infraestructura hayan aceptado el resultado.

Preguntas frecuentes

¿El modo de perfil expone el tamaño del disco de la tarea en segundo plano?

El modo de perfil usa el perfil activo para la cuota documentada en lugar de utilizar la tarea en segundo plano como identidad de recursos.

¿La cuota y los datos de aplicación son lo mismo?

No. La cuota es un valor de recursos controlado por el perfil. Bases de datos, cachés y persistencia siguen siendo cuestiones de almacenamiento de la aplicación y del navegador.

¿Cuándo entra en vigor una política del heap?

Aplíquela antes de crear la sesión o el contexto correspondiente. Inicie un runtime nuevo después de cambiarla.

¿Debe revisarse por separado la memoria del dispositivo?

Revísela junto con la cuota y el heap. Los tres valores deben corresponder a la misma clase de dispositivo.

¿Puede un despliegue usar los recursos reales del host?

Sí, cuando ese sea el objetivo explícito. Registre el modo porque el resultado puede cambiar al trasladar la carga.

¿Dónde están las opciones detalladas?

Consulte la documentación de memoria y almacenamiento para configuración y ciclo de vida. La guía de gestión de perfiles cubre el flujo general.

La protección de memoria y almacenamiento funciona como una política coherente. Alinee la cuota, el heap de JavaScript y la memoria del dispositivo, aplique los cambios antes de crear el runtime y pruebe el almacenamiento de la aplicación como una función independiente.