Planifier la capacité des BrowserContext

BrowserContext permet d’isoler le stockage et l’état de session tout en partageant le coût de démarrage du navigateur. Chaque contexte actif consomme des ressources. La pente peut changer après une mise à jour du navigateur, de l’image de l’hôte, de la page ou de la politique de profil. La planification de capacité doit mesurer le groupe de navigateurs complet au lieu de reprendre une ancienne limite de contextes.

BrowserContext sépare le stockage et l’état de session au sein d’une infrastructure de navigateur partagée. Ce n’est pas une frontière de système d’exploitation, de processus ou de sécurité. Si ces frontières sont nécessaires, utilisez un navigateur ou un hôte dédié.

BotBrowser prend en charge Per-Context Fingerprint d’ENT Tier 3, qui attribue des profils distincts à plusieurs BrowserContexts au sein d’un même processus de navigateur (isolation par contexte et benchmarks publiés). Ces benchmarks décrivent des configurations précises. BotBrowser ne garantit pas la capacité sur un autre hôte, une autre charge, un autre profil ou cycle de vie, et ne définit pas un nombre de contextes universellement sûr. Mesurez le groupe complet avant de fixer les limites d’admission.

Résumé

• Mesurez tout le groupe de navigateurs avec la version, le profil, l’hôte et la charge représentative visés ; un nombre de contextes obtenu ailleurs n’est pas une limite de capacité.
• Fixez l’admission au point de fonctionnement répétable le plus élevé ou en dessous, tout en gardant une marge pour les contextes en fermeture, le travail du navigateur et les services de l’hôte.
• Traitez la création, l’usage stable, l’inactivité, la fermeture et la récupération comme des phases distinctes ; fermer un contexte ne garantit pas un retour immédiat à la référence.
• Suspendez l’admission quand la marge est épuisée. Après récupération ou rétablissement de la version acceptée, ne la reprenez qu’après avoir confirmé le retour de la marge.

Sommaire

• Définir l’unité de version et la charge de travail
• Mesurer la courbe de capacité du groupe complet
• Définir des limites réversibles d’admission et de file
• Exploiter, récupérer et revenir en arrière
• Consigner, transmettre et revalider
• Conclusion

Définir l’unité de version et la charge de travail

Préparer une charge de travail reproductible

Choisissez un petit ensemble de charges de travail qui représente le service. Un parcours documentaire, un parcours de formulaire, une page utilisant beaucoup les graphismes et une tâche en arrière-plan peuvent avoir des pentes mémoire différentes. Utilisez des valeurs synthétiques et des destinations contrôlées. Il s’agit d’exercer le cycle de vie de la page, pas de rejouer des données client privées.

Attribuez un nom et une révision à chaque charge de travail. Notez comment une session commence, ce qu’elle fait, comment elle se termine et quand le contexte est fermé. La version acceptée et la version candidate doivent exécuter la même révision du parcours. Si l’application a changé, mettez le parcours à jour avant de comparer les versions du navigateur.

Préparez le navigateur de la même façon à chaque exécution. Certains déploiements créent un groupe de navigateurs puis admettent les contextes progressivement. D’autres créent un groupe fixe avant la première page. Choisissez le modèle réel et gardez-le stable. Un résultat à froid et un résultat avec un groupe préchauffé répondent à des questions de capacité différentes.

Consignez workloadRevision et activeContextCount à chaque exécution pour comparer la candidate à la version acceptée dans les mêmes conditions.

Classer la charge avant de compter les contextes

La planification de capacité commence par les classes de charge, et non par un chiffre unique mis en avant. Un parcours textuel, une page riche en images, une page multimédia et un rapport utilisant beaucoup les graphismes peuvent avoir des courbes de mémoire et de latence très différentes. Nommez la classe, choisissez un parcours représentatif et indiquez dans le registre l’état d’achèvement attendu.

Pour chaque classe, distinguez la création, l’utilisation active, l’inactivité et la fermeture. La création mesure le coût de démarrage. L’utilisation active montre les ressources nécessaires à la page réelle. L’inactivité révèle l’état conservé. La fermeture indique si les ressources reviennent une fois la session terminée. Le seul nombre de contextes actifs masque des étapes du cycle de vie qui peuvent dominer un service de longue durée.

Comparer le démarrage à froid et l’état préchauffé

Mesurez un groupe de navigateurs à froid et un groupe préchauffé qui a déjà terminé un parcours représentatif. Le résultat à froid aide à planifier le démarrage. Le résultat préchauffé aide à planifier le fonctionnement stable. Gardez identiques le navigateur, le profil, l’hôte, le routage, le stockage et la politique graphique afin que la différence corresponde à l’état du cycle de vie plutôt qu’à un changement d’environnement.

Si le service réutilise les contextes, notez la règle de réutilisation et l’état conservé volontairement. S’il les ferme, consignez l’action de fermeture et la période d’observation utilisée pour confirmer la récupération. Une règle de réutilisation sans politique de stockage peut laisser fuiter de l’état entre des tâches sans lien ; des fermetures trop fréquentes peuvent consacrer la capacité aux démarrages répétés.

Consigner les conditions de l’hôte et du conteneur

Le même navigateur et le même profil peuvent se comporter différemment sur un hôte plus grand, dans un conteneur plus petit ou sur un hôte dont la politique graphique diffère. Notez la classe de l’hôte, les limites du conteneur, le routage, le stockage, les extensions et le mode d’affichage avec le nombre de contextes. Ces informations permettent de décider si un ancien registre de capacité s’applique toujours. Pour le lien entre le choix de build et les ressources de l’hôte sous Linux x64, voir BotBrowser Trimmed Linux x64 : choix et validation.

En passant à une nouvelle classe d’hôte, répétez les observations à froid et à l’état préchauffé. Ne multipliez pas une recommandation par une simple règle arithmétique. La surcharge partagée du navigateur, la composition des pages et le minutage du cycle de vie peuvent modifier la forme de la courbe. Un point de fonctionnement inférieur, mesuré et assorti d’une marge, est plus utile qu’un chiffre supérieur non vérifié.

Mesurer la courbe de capacité du groupe complet

Mesurer tout le groupe de navigateurs

Commencez par un registre de version qui indique la version du navigateur, la famille de profils, la classe d’hôte, la limite du conteneur, la politique de routage, la politique de stockage et la charge représentative. Mesurez le groupe avant d’ajouter des contextes, puis répétez à plusieurs nombres de contextes actifs. Incluez des observations pendant la création, l’état stable, l’inactivité et la fermeture.

Le résultat utile n’est pas un chiffre universel, mais une courbe de capacité pour la version et la charge exactes :

• Mémoire de base avant le premier contexte.
• Mémoire incrémentale lorsque les contextes sont actifs.
• Latence de création lorsque la concurrence augmente.
• Récupération après la fermeture d’un contexte.
• Marge de l’hôte après le nettoyage.

Lire la courbe mémoire

Mesurez plus de deux nombres de contextes. Une valeur de base et un maximum peuvent masquer un changement brusque, un plateau ou un délai de nettoyage. À chaque point, notez activeContextCount, groupMemory, creationLatency, closeLatency, l’achèvement de la page et la récupération après fermeture.

La pente est utile lorsqu’elle reste assez stable, mais ne supposez pas une croissance linéaire. Une page peut charger un worker ou une ressource multimédia après le démarrage du contexte. Une version du navigateur peut ajouter un processus partagé lorsqu’une limite de ressources est franchie. La limite opérationnelle doit réserver de la place à ces changements et aux tâches déjà en cours.

Observez l’ensemble du groupe de navigateurs. Les mesures par contexte peuvent omettre les processus du navigateur, la mémoire partagée, les tampons graphiques, les pools réseau et la surcharge de l’hôte ou du conteneur. La capacité concerne le groupe que les opérations peuvent réellement mettre en pause et vider.

Choisir des points de mesure utiles

Choisissez des points qui correspondent à la décision opérationnelle. Un petit groupe montre le comportement au démarrage. Un groupe moyen représente la file normale. Un groupe plus grand peut révéler le moment où changent la latence de création, la pression mémoire ou le nettoyage. Arrêtez avant que l’hôte n’atteigne un état dangereux et notez la raison de l’arrêt.

Une mesure doit clarifier la décision suivante. Si le groupe reste bien sous sa limite, admettez le prochain lot borné. Si la récupération ralentit, suspendez le groupe et laissez-le se vider. Si le résultat est instable, répétez le même point avec la version acceptée avant de changer la charge.

Inclure la surcharge du navigateur et de l’hôte

La mémoire des contextes ne représente qu’une partie du groupe. Les processus du navigateur, la mémoire partagée, les tampons graphiques, les pools réseau, les descripteurs de fichiers, l’activité disque et les services de l’hôte ont eux aussi besoin d’espace. Une estimation par contexte peut sembler sûre alors que le groupe de navigateurs approche déjà de sa limite opérationnelle.

Consignez les limites de l’hôte et du conteneur. Un hôte plus grand peut permettre un autre point de fonctionnement, mais ne rend pas universel un résultat lié à une version précise. Recalculez la courbe après l’agrandissement de l’hôte ou un changement de limite du conteneur.

Comparer des pages légères et représentatives

Une page légère peut montrer le coût de démarrage de base. Une page représentative montre les ressources réellement nécessaires en production. Gardez les deux mesures si le service prend en charge les deux classes. Ne transposez pas à une charge multimédia ou graphique une limite élevée mesurée sur une page légère ; il faut une mesure distincte.

Pour chaque classe, consignez les mêmes champs : navigateur et profil, hôte, routage, stockage, extensions, politique graphique, nombre de contextes actifs, mémoire, latence, achèvement, comportement de fermeture et récupération. N’incluez pas les détails sensibles des pages dans le résumé partagé, mais gardez assez de contexte opérationnel pour comparer les courbes.

Exécuter les vérifications d’acceptation

Exécutez ces vérifications de réussite ou d’échec dans votre propre environnement et conservez un résultat consigné pour chacune. N’acceptez une capacité qu’après la réussite des vérifications 1, 2 et 4 à 7.

1. Référence : avec zéro contexte ouvert, consignez la mémoire et le CPU de l’hôte ainsi que la mémoire du groupe de navigateurs. Réussite si la référence est consignée et reproductible d’une lecture à l’autre.
2. Test par paliers : augmentez le nombre de contextes actifs en au moins trois paliers. Maintenez chaque palier en usage stable puis en période d’inactivité avant de consigner activeContextCount, groupMemory, creationLatency et le nombre d’erreurs. Réussite si le palier reste dans votre propre budget de latence et d’erreurs et si l’hôte conserve de la marge.
3. Capacité acceptée : consignez-la comme le palier le plus élevé où la vérification 2 réussit, et fixez la limite d’admission à cette valeur ou en dessous.
4. Récupération à la fermeture : ouvrez et fermez des contextes sur N cycles, avec N assez grand pour qu’une tendance apparaisse. Réussite si la mémoire se stabilise près de la référence et ne croît pas de façon monotone d’un cycle à l’autre. La fermeture ne rend pas forcément toute la mémoire, donc expliquez tout écart résiduel au lieu de le supposer inoffensif.
5. Requête en file : remplissez le groupe jusqu’à sa limite et soumettez une requête de plus. Réussite si elle est admise dans l’attente indiquée, ou rejetée ou différée avec un signal clair qui parvient au responsable du groupe.
6. Pause et reprise : poussez le groupe au-delà de son seuil de pause. Réussite si l’admission se met en pause et ne reprend qu’une fois la marge rétablie.
7. Nouvelle exécution : répétez les vérifications 1 à 6 après une mise à jour du navigateur, un renouvellement de profil, un changement d’hôte ou de conteneur, une révision de page ou un changement de cycle de vie.

Définir des limites réversibles d’admission et de file

Définir un budget avec une marge

Le budget doit indiquer la limite normale de fonctionnement, le seuil de pause, le seuil de récupération et la personne autorisée à les changer. Gardez assez de ressources pour un contexte en cours de fermeture, un processus de navigateur qui redémarre et les services nécessaires sur l’hôte.

Ne déduisez pas la limite de la seule mémoire disponible. Le processeur, les descripteurs de fichiers, la mémoire partagée, les connexions réseau, l’espace disque et le temps de réponse des pages peuvent limiter le service en premier. Notez la mesure qui arrête l’admission et celles qui expliquent pourquoi la limite a été atteinte.

Réexaminez le budget après l’agrandissement de l’hôte. Plus de mémoire ne rend pas automatiquement sûre une concurrence supérieure avec une ancienne version du navigateur ou une charge de pages. Reproduisez la même courbe, puis faites modifier la limite par une personne responsable et définissez la condition de retour arrière.

Observer le comportement de la file

Le contrôle d’admission est plus facile à exploiter lorsque l’état de la file est visible. Consignez le travail en attente, les contextes actifs, le travail terminé, queueAge de l’élément le plus ancien et l’action prise au seuil de pause. Une file bornée peut rejeter ou différer le nouveau travail tandis que les sessions actives se terminent sans risque.

Ne laissez pas une boucle de nouvelle tentative masquer un groupe de navigateurs plein. Des échecs répétés de création signalent qu’il faut mettre en pause ou vider le groupe, pas ajouter du travail. Documentez l’action de récupération et rendez-la accessible à la personne qui exploite le groupe.

Rendre l’admission réversible

Le contrôle d’admission doit avoir une personne responsable et une action réversible. Lorsque le groupe atteint son point de fonctionnement approuvé, suspendez le nouveau travail ou différez-le dans une file bornée. Laissez les parcours actifs se terminer, puis vérifiez si la mémoire et la latence reviennent. Ne masquez pas un groupe plein derrière des nouvelles tentatives ou une file sans limite.

Le registre de récupération doit préciser l’action de la personne d’exploitation, les tâches terminées et les changements constatés après la vidange du groupe. Si les ressources ne sont pas récupérées, conservez la référence acceptée et examinez une classe de charge à la fois. Augmenter la concurrence avant de comprendre la récupération rend la mesure suivante plus difficile à interpréter.

Ne séparer les groupes qu’en cas de besoin

Séparez les groupes lorsqu’une charge a une limite opérationnelle ou une voie de récupération réellement différente. Un parcours multimédia peut avoir besoin de limites différentes d’une tâche textuelle. Une cible mobile peut nécessiter une autre classe d’hôte. Gardez assez peu de groupes pour que les équipes comprennent chaque budget.

Chaque groupe doit avoir un nom, une classe de charge, une paire navigateur-profil, une classe d’hôte, une politique de routage et de stockage, une personne responsable de l’admission, une limite acceptée, un seuil de pause, une règle de récupération et un paquet de retour arrière. Un groupe sans responsable n’est pas une limite opérationnelle.

Exploiter, récupérer et revenir en arrière

Couvrir les phases du cycle de vie

Un service qui crée rapidement de nombreux contextes peut nécessiter une limite de création même si la mémoire en état stable reste acceptable. Un service qui garde des sessions ouvertes pendant des heures doit vérifier la récupération après une longue période d’inactivité.

Classez chaque observation dans lifecyclePhase (création, activité, inactivité ou fermeture), puis consignez recoveryResult après la vidange du groupe.

Fermez les contextes avec le cycle de vie pris en charge et attendez le signal normal de nettoyage avant d’ouvrir le groupe de test suivant. Notez si la mémoire revient dans la plage attendue. Sinon, ne qualifiez pas tout de suite la différence de problème de capacité : vérifiez d’abord les pages, téléchargements, ressources multimédias, workers et extensions.

Le contrôle d’admission doit laisser le nettoyage s’effectuer. Suspendre le nouveau travail permet aux sessions actives de se terminer et au navigateur de libérer ses ressources. Une boucle de nouvelle tentative qui crée un autre contexte alors que l’hôte est sous pression peut transformer un incident récupérable en panne.

Exploiter un groupe de longue durée

Les groupes de longue durée nécessitent une fenêtre d’observation adaptée au service. Surveillez le nombre de contextes actifs, la mémoire du groupe, la mémoire disponible, les latences de création et de fermeture, l’âge de la file, le travail terminé et la récupération après la vidange. Utilisez des valeurs agrégées, sans enregistrer le contenu privé des pages.

Lorsqu’une mesure dépasse le seuil de pause, arrêtez d’abord l’admission. Laissez les tâches sans risque se terminer, videz les contextes selon la politique et rétablissez la version acceptée si la candidate ne récupère pas. Notez si le groupe revient à sa plage précédente. Sinon, gardez-le en pause et examinez la charge ou l’hôte avant de promouvoir la version.

Vérifier les choix de fermeture et de réutilisation

Certains services ferment un contexte après chaque tâche. D’autres le réutilisent pour une session contrôlée. Mesurez le cycle de vie réellement prévu par le service. La réutilisation peut éviter le coût de démarrage, mais elle exige une politique claire de stockage et de session. La fermeture peut réduire l’état conservé, mais elle ajoute du travail de création.

Le bon choix dépend de l’application et de la politique de confidentialité. Consignez-le dans le registre de capacité. Si un contexte réutilisé change l’état attendu, ne le réutilisez pas pour une tâche sans lien. Si un contexte fermé ne permet pas la récupération des ressources, suspendez l’admission et examinez la charge avant d’augmenter la concurrence.

Consigner, transmettre et revalider

Comparer les changements de navigateur et de profil

Une version de maintenance du navigateur peut modifier la mémoire, le démarrage, l’organisation des processus ou le comportement à la fermeture alors que la page semble toujours correcte. Une actualisation du profil peut modifier les graphismes, la langue, le stockage ou les permissions et donc changer la charge de la page. Séparez ces changements lors de la première comparaison.

Associez la version du navigateur au paquet de profils correspondant. Figez la classe d’hôte, les politiques de routage et de stockage, les extensions et la révision de la charge. Mesurez d’abord la paire acceptée, puis la candidate. Si la candidate demande une mesure temporaire, consignez la raison, l’effet mesuré et la condition de retrait.

Ne publier que les informations utiles

Lorsque vous partagez des résultats de capacité, présentez des mesures agrégées sans détails sur les hôtes des clients, échantillons mémoire privés, noms de processus internes ni chiffre susceptible de passer pour une limite universelle. Mesurez la version, le profil, l’hôte et la charge de votre propre déploiement.

Modèle de registre de capacité

Gardez un registre par version du navigateur et classe de charge. Indiquez la compilation exacte du navigateur, la famille de profils, la plateforme cible, la mémoire de l’hôte, la limite du conteneur, les politiques d’affichage et graphiques, de routage et de stockage, workloadRevision, activeContextCount, groupMemory, creationLatency, closeLatency, lifecyclePhase, queueAge, recoveryResult, la limite de fonctionnement acceptée, la condition de retour arrière et la personne responsable.

Consignez ces mesures de charge de travail et de cycle de vie :

Champ	À consigner
workloadRevision	La révision du parcours fixe utilisée pour la comparaison
activeContextCount	Les contextes actifs simultanément à chaque étape
groupMemory	La mémoire du groupe de navigateurs à chaque point de mesure
creationLatency	La latence de création de contexte à chaque étape
closeLatency	La latence de fermeture et la reprise après fermeture
lifecyclePhase	Création, utilisation active, inactif ou fermeture
queueAge	L’âge de la plus ancienne requête en file au point de décision
recoveryResult	Si le groupe est revenu à sa plage de fonctionnement acceptée

Rouvrez le registre après tout changement du navigateur, de l’hôte, du profil, de la page, des extensions, des graphismes ou du réseau. La planification de capacité est un contrôle continu de version, pas un test de performance ponctuel.

Lier la recommandation à la version

Un chiffre de capacité correspond à une version du navigateur, une famille de profils, une classe d’hôte, une charge et une politique d’exploitation. Revérifiez-le après une maintenance du navigateur, une actualisation du profil, une révision de page, une mise à jour d’extension, un changement graphique ou de routage, ou une modification de l’image de l’hôte. Le registre reste utile même si sa limite doit changer.

Le guide Scaling BrowserContexts présente l’isolation des contextes et les compromis généraux liés aux ressources. Cette page traite des courbes mémoire mesurées, de l’observation prolongée, de l’admission et de la récupération. Browser Release Validation présente le processus plus large de promotion d’une version candidate.

Préparer une transmission pratique de capacité

Avant la mise en production d’un groupe, transmettez la paire navigateur-profil, la classe d’hôte, workloadRevision, la limite de fonctionnement acceptée, le seuil de pause, la règle de récupération et le paquet de retour arrière. Nommez la personne qui peut suspendre l’admission. Une file sans responsable transforme une mesure en supposition.

Précisez la fenêtre de mesure et les conditions non testées. Si la courbe couvre un parcours textuel mais pas le multimédia, indiquez-le. Si l’observation a duré trente minutes alors que le service fonctionne toute la nuit, planifiez une fenêtre plus longue au lieu de présenter le résultat court comme une preuve de longue durée.

Gardez le registre près du processus de version. Rouvrez-le après une version majeure du navigateur, une actualisation du profil, une révision de page, une image d’hôte, une extension, une pile graphique, une politique de routage ou une politique de stockage modifiée. Un petit registre reproductible évite au service de conserver discrètement un ancien budget de contextes.

Si le service comporte plusieurs files, tenez un registre pour chacune. Une file de tâches textuelles courtes peut se vider rapidement pendant qu’une file de rapports volumineux reste active. Les regrouper peut faire paraître bloquée une file saine, ou faire croire qu’une file occupée a de la capacité disponible. Dans chaque revue, nommez la file, la classe de charge et la personne responsable afin que la décision d’exploitation vise le bon parcours du service.

Lorsqu’un groupe atteint sa limite de fonctionnement, la première action doit être opérationnelle, pas spéculative : arrêtez les nouvelles admissions, laissez les tâches sans risque se terminer et observez la récupération. Rétablissez la version acceptée si la candidate ne revient pas dans la plage approuvée. Examinez ensuite la charge avec une référence stable.

Sources publiques

• Optimisation des performances de BotBrowser: Conseils sur la mémoire du groupe et le réglage du démarrage
• Isolation par contexte de BotBrowser: Profils par contexte dans un seul processus de navigateur
• Méthodologie de benchmark de BotBrowser: Matériel testé, build, méthode et résultats d’échelle et de cycle de vie par contexte
• BrowserContexts de Playwright: Isolation du stockage, de la session et des cookies de BrowserContext

Conclusion

Il n’existe pas de nombre sûr de contextes applicable à tous les environnements. N’acceptez une limite qu’après l’exécution de la charge représentative, le respect des budgets de latence et de ressources, puis la récupération du groupe après fermeture et vidage. Gardez l’admission réversible : suspendez-la au seuil consigné, reprenez après récupération et refaites les mesures lorsque le navigateur, le profil, la charge, l’hôte ou le cycle de vie change. Un chiffre de capacité dépend aussi de l’endroit où le navigateur s’exécute, car un endpoint géré remplace une mesure locale par un plafond de session publié : navigateur géré contre navigateur auto-hébergé compare les deux structures de coût.