Signaux de mémoire et de stockage des profils

Les applications web ont besoin d'informations sur les ressources pour gérer de grands documents, des médias et des tâches longues. Certaines de ces informations décrivent aussi la machine hôte. La capacité de stockage et la classe de mémoire peuvent donc contribuer à la corrélation entre sessions lorsqu'elles ne correspondent pas au reste du profil.

BotBrowser place trois familles de ressources sous le contrôle du profil : le quota de stockage, la limite du tas JavaScript et la mémoire de l'appareil. L'objectif est une identité cohérente sur les hôtes pris en charge, pas une collection de valeurs fixes sans rapport.

Ce point compte dans une flotte de serveurs. Un profil peut s'exécuter sur une station, une machine virtuelle ou un conteneur tout en représentant la même famille d'appareils. La politique fondée sur le profil empêche l'allocation de l'hôte de devenir l'identité du navigateur par défaut.

Pourquoi les ressources affectent la confidentialité

L'identité du navigateur réunit des propriétés liées. Plateforme, famille de navigateur, écran, processeur, mémoire et stockage doivent décrire ensemble un appareil plausible. Lorsqu'une propriété reflète le serveur hôte et que les autres suivent le profil, cette incohérence peut faciliter la corrélation des sessions.

Les valeurs peuvent aussi changer lorsqu'une tâche passe d'une machine à une autre. Un job exécuté aujourd'hui dans un petit conteneur et demain sur une grande station ne devrait pas exposer ce changement d'infrastructure si le même profil reste actif.

La cohérence est plus utile qu'une valeur universelle. Un profil mobile et un profil de station de travail ne doivent pas présenter la même classe de ressources simplement parce qu'ils partagent un serveur. Les valeurs doivent suivre la famille du profil et rester stables pendant le cycle de vie prévu.

Les trois familles contrôlées

Quota de stockage

Le quota décrit le budget de stockage géré par le navigateur pour le contenu web. Lorsqu'il dépend entièrement de la machine, il peut refléter les caractéristiques du disque hôte.

En mode profil, BotBrowser fournit un quota aligné sur le profil actif plutôt que sur le disque hôte. La session conserve ainsi la même identité de ressources lorsqu'elle se déplace entre des systèmes pris en charge.

Limite du tas JavaScript

La limite du tas décrit le budget mémoire du runtime JavaScript. Elle doit correspondre à la classe d'appareil représentée par le profil. Un profil mobile léger et un profil de bureau riche en mémoire appartiennent naturellement à des classes différentes.

BotBrowser peut appliquer la politique du profil aux nouvelles sessions et aux nouveaux contextes. Le moment du cycle de vie est important, car la limite doit être établie lors de la création du runtime.

Mémoire de l'appareil

La mémoire de l'appareil est un signal général qui représente la classe de mémoire. BotBrowser l'aligné sur le profil actif afin que la classe d'appareil et la politique du runtime ne se contredisent pas.

Ces trois valeurs racontent une seule histoire de ressources. Leur examen commun évite qu'un profil présente un appareil à faible mémoire tout en exposant un budget beaucoup plus grand ou une classe de stockage sans rapport.

Politiques de profil, d'hôte et explicites

Le comportement fondé sur le profil est le choix habituel pour une validation de confidentialité reproductible. Le profil reste la source de l'identité prévue même si la tâche d'arrière-plan change.

Certaines tâches autorisées doivent suivre les ressources réelles de l'hôte. Ce mode convient lorsque l'hôte est le sujet du test ou lorsque la capacité de l'application doit refléter la tâche d'arrière-plan. Il doit être choisi délibérément, car le déplacement du même profil peut alors modifier le comportement.

Une politique explicite peut servir un test de compatibilité contrôlé où une classe connue fait partie du plan. Documentez-la comme une configuration de test, pas comme une valeur isolée sans lien avec le profil.

La documentation du quota de stockage décrit les options prises en charge et les règles de cycle de vie.

Périmètre de la politique

Les contrôles documentés de BotBrowser couvrent le quota de stockage, la limite du tas JavaScript et la mémoire de l'appareil. Ces trois familles doivent être examinées comme un groupe fondé sur le profil.

Les systèmes de données d'origine conservent leur sémantique normale de navigateur. Les bases de données d'application, le contenu des caches et la persistance ne sont pas interchangeables avec ces contrôles. Testez ces fonctions comme un comportement produit ordinaire sans supposer qu'un réglage de ressources modifie tous les sous-systèmes de stockage.

Cette limite facilite le diagnostic. Un quota incohérent appartient à l'examen du profil. Une donnée d'application manquante ou un problème de cache appartient au cycle de vie du stockage du site. Séparer ces questions évite d'étendre à tort le périmètre du profil.

Cohérence entre hôtes

Une flotte partagée contient souvent des machines avec des allocations différentes. Le mode profil donne à ces tâches d'arrière-plan une identité de ressources commune pour une même famille de profils.

Il prend en charge plusieurs modèles :

• Un profil peut passer entre Windows, macOS et Linux sans adopter la classe de chaque hôte.
• Un tâche d'arrière-plan headless peut conserver l'identité prévue d'une session de contrôle avec interface.
• Un nouveau contexte reçoit la politique de tas au moment de la création du runtime.
• Un tâche d'arrière-plan multi-contextes peut aligner chaque contexte sur son profil affecté.

La cohérence entre hôtes ne signifie pas que tous les profils présentent les mêmes valeurs. Elle signifie que le profil choisi reste la source de vérité au lieu de la tâche d'arrière-plan actuel.

Choix de déploiement

Profils persistants

Un profil persistant doit garder une politique stable pendant son cycle de vie. Examinez la politique avant de le déplacer vers une autre classe de tâche d'arrière-plan, surtout si le déploiement précédent suivait volontairement l'hôte.

Contextes de test jetables

Les contrôles qualité courts bénéficient du mode profil, car un nouveau tâche d'arrière-plan ne change pas silencieusement l'identité attendue. Créez un nouveau contexte après une modification de la politique de tas.

Tests de capacité et de compatibilité

Lorsqu'un test mesure volontairement la capacité de l'hôte, documentez ce choix séparément de la validation de confidentialité. Un même résultat ne prouve pas les deux objectifs, car l'un suit la tâche d'arrière-plan et l'autre le profil.

Familles d'appareils mixtes

Une flotte mobile et bureau doit examiner chaque famille séparément. Réutiliser un réglage unique peut créer des incohérences même si la valeur semble plausible seule.

Validation défensive

Commencez par la configuration et les résultats de l'application, sans script de collecte dans la page.

1. Confirmez la politique de ressources attendue par le job.
2. Confirmez que le profil prévu est actif avant la session ou le contexte.
3. Examinez ensemble quota, tas JavaScript et mémoire de l'appareil.
4. Exécutez le parcours autorisé et observez le comportement fonctionnel face aux limites.
5. Répétez sur un autre hôte pris en charge si la cohérence entre hôtes est exigée.
6. Notez la famille de profil, le mode, la classe d'hôte et le résultat de l'application.

Avec plusieurs contextes, validez chacun après sa création. Une configuration correcte au niveau du processus ne prouve pas que chaque contexte ultérieur a reçu les bons paramètres de cycle de vie.

En mode profil, le résultat attendu vient du profil et non de l'hôte réel. Le mode hôte sert un autre objectif et doit être identifié clairement dans les dossiers de test.

Erreurs courantes

Examiner chaque valeur séparément

Un quota peut sembler plausible tandis que le tas et la mémoire décrivent un autre appareil. Approuvez le groupe complet.

Changer la politique de tas après la création

La politique appartient au cycle de création. Démarrez une nouvelle session ou un nouveau contexte après une modification.

Confondre stockage applicatif et ressources du profil

Les données, caches et comportements de persistance gardent leur fonctionnement normal. Testez-les selon les exigences fonctionnelles de l'application.

Laisser un changement de tâche d'arrière-plan redéfinir le profil

Lorsque la cohérence est requise, gardez le mode profil lors des déplacements. Choisissez le mode hôte seulement si le test l'exige.

Utiliser une politique pour des appareils sans rapport

Les ressources doivent correspondre à la classe sélectionnée. Examinez séparément les familles mobiles, bureau et autres.

Établir une référence de version

Choisissez des tâches autorisées qui utilisent normalement le stockage et la mémoire, comme enregistrer un brouillon, ouvrir un document volumineux, charger un espace média ou exporter un rapport. Consignez la famille de profil, BotBrowser, l'application, la classe de worker, le mode de politique et le résultat. Exécutez cette référence sur chaque classe d'hôte prévue et séparez les résultats de confidentialité des mesures de capacité.

Déplacer des profils entre classes de workers

Commencez par un groupe de test et confirmez que la destination prend en charge la même version. Un déploiement fondé sur le profil ne doit pas adopter silencieusement le comportement de l'hôte. Arrêtez le worker source avant de démarrer un profil persistant sur la destination, puis validez la migration avant de l'étendre.

Examiner les incidents liés aux ressources

Classez d'abord le symptôme visible : échec d'enregistrement, document lent, onglet terminé ou données hors ligne absentes. Reproduisez la tâche avec les versions et le mode enregistrés. Comparez la dernière combinaison approuvée à la candidate en ne changeant qu'un composant, et distinguez la capacité réelle de l'hôte de la politique du profil.

Conserver des preuves proportionnées

Utilisez des comptes de test et des documents synthétiques. Conservez le résultat, les versions et la décision, sans enregistrer de secrets ni d'historique de navigation. Attribuez des propriétaires distincts à l'application, au profil et à l'infrastructure, car chacun approuve une partie différente du déploiement.

Examiner les travaux de longue durée

Ajoutez une tâche assez longue pour créer des données applicatives ordinaires, changer de page et libérer les ressources temporaires. Vérifiez que le parcours reste utilisable et que le résultat correspond à la famille de profil approuvée. Consignez la pression réelle du worker séparément de la décision sur la politique du navigateur.

Rejouez la tâche après un redémarrage du service et après le nettoyage normal de l'application. Un parcours qui ne réussit que sur une image neuve peut révéler un problème opérationnel lié aux données conservées. Utilisez des comptes dédiés et des contenus synthétiques.

Gérer le remplacement des workers

Avant de remettre un nouveau worker dans le pool, installez la même combinaison approuvée de navigateur, profil, service et application. Exécutez d'abord la référence courte. Le remplaçant doit terminer le même parcours, même si son disque physique et sa mémoire diffèrent de l'ancien hôte.

Écartez les workers défaillants des nouvelles tâches jusqu'à la revue de leurs données applicatives. Un remplacement ne doit pas déplacer silencieusement un travail incomplet ni réutiliser un répertoire inconnu. Suivez la politique de reprise et de conservation de l'application.

Définir les décisions de version et de retour

Écrivez la règle d'acceptation avant le test. Le candidat doit terminer les parcours, conserver la politique de profil approuvée, respecter le budget de l'hôte et reprendre proprement après un redémarrage. Chaque résultat indique son propriétaire.

Le retour restaure la dernière combinaison complète approuvée. Exécutez ensuite la référence courte et confirmez la reprise du traitement. Conservez les preuves du candidat pour la revue sans mélanger ses composants dans le pool restauré.

Observez ensuite la combinaison restaurée pendant la période habituelle. Vérifiez l'avancement des tâches, la croissance du disque, les redémarrages et la pression mémoire avant de clore la revue.

Associez la décision finale à la version, au profil, à la classe de worker et au parcours contrôlé. Conservez le résultat du candidat et celui de la combinaison restaurée dans la même revue. Le responsable peut alors confirmer que les données applicatives restent disponibles, que le traitement reprend normalement et que le retour n'a pas déplacé le problème vers un autre groupe.

Questions fréquentes

Le mode profil expose-t-il la taille du disque de la tâche d'arrière-plan ?

Le mode profil utilise le profil actif pour le quota documenté au lieu d'utiliser la tâche d'arrière-plan comme identité de ressources.

Le quota et les données d'application sont-ils identiques ?

Non. Le quota est une valeur de ressources contrôlée par le profil. Bases de données, caches et persistance restent des questions de stockage de l'application et du navigateur.

Quand une politique de tas prend-elle effet ?

Appliquez-la avant de créer la session ou le contexte concerné. Démarrez un nouveau runtime après une modification.

Faut-il examiner la mémoire de l'appareil seule ?

Examinez-la avec le quota et le tas. Les trois valeurs doivent soutenir la même classe d'appareil.

Peut-on utiliser les ressources réelles de l'hôte ?

Oui, si c'est l'objectif explicite du test. Consignez le mode, car le résultat peut changer après un déplacement vers un autre hôte.

Où trouver les réglages détaillés ?

Consultez la documentation mémoire et stockage pour la configuration et le cycle de vie. Le guide de gestion des profils couvre le parcours général.

La protection de la mémoire et du stockage fonctionne comme une politique cohérente. Alignez le quota, le tas JavaScript et la mémoire de l'appareil, appliquez les changements avant la création du runtime et testez le stockage applicatif comme une fonction distincte.