Limites de ressources d’un conteneur de navigateur : méthode pratique

Les limites d’un conteneur répondent à une question opérationnelle : quelle quantité de CPU et de mémoire cette charge de navigateur peut-elle consommer ? Elles ne disent pas si le navigateur est privé, si deux sessions appartiennent à des personnes différentes, ni si une page se comportera pareil sur chaque hôte. Une bonne planification sépare ces questions.

BotBrowser peut répéter une charge autorisée dans un profil, une version, une route et une plateforme déclarés, puis comparer les résultats visibles sous des budgets documentés. Il ne peut pas allouer la capacité de l’hôte, garantir un débit, affaiblir l’isolation du navigateur ou déduire une identité personnelle à partir des ressources.

Définir la charge avant les limites

Commencez par une charge déclarée, pas par une taille de conteneur préférée. Notez la version du navigateur, la classe de profil, la route de test maîtrisée, les étapes de navigation, le résultat attendu, la concurrence, la politique de stockage et la présence de graphiques ou de médias. Une page textuelle et une page graphique peuvent avoir des courbes mémoire différentes avec la même image.

L’observation doit rester bornée. Mesurez seulement ce qui sert à décider : démarrage, achèvement, pression CPU, pression mémoire, attente en file et récupération après fermeture d’un worker. Une observation de ressources n’est pas une conclusion de fingerprinting. Ne conservez pas de dumps bruts si un résultat succès/échec et un budget déclaré suffisent.

Utiliser une table de décision

Choisissez le budget initial selon la charge et la concurrence réelles. Cette table aide à planifier, elle ne garantit pas une capacité universelle.

Signal	Première décision	Vérification avant d’augmenter la concurrence
Document léger, une ou deux sessions, achèvement stable	Commencer avec des demandes CPU/mémoire bornées et garder une marge hôte	Refaire la mesure après une mise à jour du navigateur ou de la page
Plusieurs pages, attente croissante	Maintenir la concurrence et mesurer tout le conteneur	Vérifier pente mémoire, bridage CPU et récupération
Page média ou graphique sous pression répétée	Réduire l’admission ou séparer la classe de charge	Confirmer mémoire partagée, politique graphique et arrêt propre
Limite mémoire atteinte avant la fin	Ne plus admettre de travail et conserver l’échec	Augmenter seulement après reproduction avec données synthétiques

La règle est simple : si le résultat ne se termine pas dans le budget déclaré, réduire l’admission ou changer de classe avant d’augmenter la limite. Une limite plus élevée peut masquer une fuite ou une file sans borne.

Séparer limites et signaux du navigateur

Docker et Kubernetes contrôlent les ressources du conteneur ou du pod. Des API comme navigator.hardwareConcurrency donnent une indication de l’environnement à la page, pas une mesure de la capacité restante du conteneur. Traitez-les comme un contexte, pas comme une identité. Deux conteneurs avec la même indication peuvent avoir des limites différentes.

La frontière de confidentialité compte aussi. Une combinaison stable d’indications de ressources, de labels de profil, de routes et d’horodatages peut devenir corrélable. Conservez la version, la classe de charge et la décision budgétaire ; omettez les valeurs brutes et identifiants inutiles. Révisez conservation et accès comme pour le stockage du navigateur.

Surveiller et récupérer méthodiquement

Surveillez le groupe complet : processus navigateur, mémoire partagée, buffers graphiques, pools réseau et compteurs CPU/mémoire du conteneur. Les chiffres par onglet aident au diagnostic mais ne constituent pas le contrat de capacité. Notez démarrage, résultat, fermeture et récupération suffisante pour la prochaine série bornée.

Appliquez des actions ordonnées : arrêter les nouvelles admissions, terminer ou annuler le parcours maîtrisé, fermer le contexte et consigner le résultat. Si la pression ne revient pas, conservez la charge minimale reproductible et arrêtez le conteneur au lieu de la relancer indéfiniment.

Comparer BotBrowser dans ses limites

Pour comparer deux versions autorisées de BotBrowser, fixez profil, route, charge, limites et concurrence. Comparez les résultats visibles et observations déclarées avec leurs conditions et limites. Une différence soutient un suivi propre à la version ; elle ne prouve ni cause du noyau, ni performance universelle, ni identité.

Consignez la révision de charge, la version, la classe de profil, le budget, la concurrence, le résultat, l’incertitude, la conservation et l’action suivante. Un autre opérateur peut ainsi répéter la décision sans recevoir de données privées ni de recette de détecteur.

Sources

• Contraintes de ressources Docker
• Gestion des ressources des conteneurs Kubernetes
• MDN : Navigator.hardwareConcurrency
• Fonctions avancées BotBrowser

Lectures associées : guide de déploiement Docker pour navigateur et planification de capacité BrowserContext.

Décrivez le parcours avec des étapes reproductibles et un critère visible de fin.

Commencez avec une faible concurrence et augmentez-la seulement après la fermeture et la récupération.

Notez la phase où apparaît la pression : démarrage, régime stable, file ou fermeture.

Séparez la demande de l’orchestrateur, la limite du conteneur et le délai de l’application.

Une file bornée protège l’hôte et évite les relances qui multiplient l’état retenu.

Après un changement d’image, de profil ou de route, répétez la comparaison avec la même charge synthétique.

Le résultat obtenu sur un grand hôte ne rend pas sa capacité universelle.

Conservez uniquement les mesures grossières qui changent la décision d’admission.

Évitez le texte de page, les identifiants de compte et les destinations complètes lorsqu’une classe de route suffit.

Attribuez un responsable à chaque action suivante d’admission, d’image, de route ou de récupération.

Une différence de ressources ne prouve ni une cause du moteur ni l’identité d’une personne.

Si la limite est atteinte, préservez le cas minimal reproductible avant de modifier le budget.

La récupération après fermeture du contexte est une vérification distincte de l’achèvement.

Réexaminez la conservation lorsque les valeurs exactes n’influencent plus l’exploitation.

BotBrowser répète des observations autorisées dans des conditions déclarées ; il n’alloue pas la capacité de l’hôte.

Ce contrat opérationnel garde la comparaison utile sans créer un inventaire superflu de signaux.