BotBrowser Trimmed Linux x64 : choix et validation

BotBrowser Standard et BotBrowser Trimmed répondent à des contraintes opérationnelles différentes. Standard reste le choix général pour les sessions interactives, les parcours longs et les applications qui utilisent une large surface fonctionnelle du navigateur. Trimmed est une distribution ENT Tier 3 destinée en priorité aux sessions courtes sur Linux x64, lorsque le temps de préparation d'un contexte et les pics de ressources pèsent fortement dans le coût total d'une exécution. BotBrowser peut proposer une distribution plus légère pour des sessions courtes autorisées dans un contexte contrôlé ; il ne peut pas garantir le même résultat sur un autre hôte, une autre version ou une autre charge de travail.

Résumé

• Standard conserve la surface complète du navigateur pour les sessions longues ou interactives ; Trimmed vise les sessions courtes et répétées sous Linux x64 où la préparation revient à chaque tâche.
• Dans la comparaison publiée sur le même hôte, Trimmed a terminé plus vite la charge courte avec moins de pression sur le processeur et la mémoire, tout en gardant le résultat et la fermeture.
• Mesurez le cycle complet avec /usr/bin/time -v et VmHWM lu dans /proc/<pid>/status, pas une seule navigation.
• Plafonnez le pool en cgroup v2 avec memory.current, memory.max et un plafond MemoryMax=2G, en gardant une marge de reprise sous la limite observée.
• Déployez d'abord sur un petit groupe candidat avec un retour arrière répété ; toute différence de fonction, de résultat ou de fermeture ramène la charge sur Standard.

Sommaire

• Choisir la version adaptée à la charge
• Interpréter les résultats publics dans leur contexte
• Quand retenir Standard ou évaluer Trimmed
• Construire une comparaison reproductible
• Exécuter une QA autorisée et planifier la capacité
• Définir le budget, l'acceptation et le retour arrière
• Conclusion pratique

Choisir la version adaptée à la charge

Le choix ne doit pas reposer uniquement sur une moyenne publiée. Une charge composée de pages légères, de validations courtes et de fermetures fréquentes ne se comporte pas comme une application riche conservée plusieurs heures. La route réseau, le contenu des pages, la durée des sessions, le nombre d'actions et les artefacts conservés changent tous le résultat. La bonne décision consiste donc à partir du benchmark public, puis à reproduire la comparaison avec un échantillon autorisé de votre propre charge.

Trimmed ne remplace pas Standard. Il ajoute une option de déploiement pour les équipes dont la capacité est limitée par le démarrage, la première navigation, le processeur ou la mémoire. Si ces coûts représentent une petite partie du parcours complet, Standard peut rester le choix le plus simple. S'ils reviennent à chaque session et dominent le temps total, Trimmed mérite une validation structurée.

Interpréter les résultats publics dans leur contexte

La comparaison publique oppose BotBrowser Standard à BotBrowser Trimmed sur le même hôte Linux x64, avec une charge autorisée et des conditions équivalentes. La version principale, le paquet de profils, la destination et le déroulement sont restés identiques. La fermeture a été contrôlée après chaque répétition. La méthode de référence est disponible dans la section Trimmed du benchmark public.

Dans cet environnement contrôlé, Trimmed a terminé la charge de sessions courtes plus rapidement et a réduit la pression sur le processeur et la mémoire. Les deux versions ont achevé le travail représentatif et rendu l'hôte à un état opérationnel propre. Ce résultat justifie une évaluation de Trimmed lorsque la préparation répétée occupe une part significative du temps total.

Le maintien du résultat attendu et la libération des ressources comptent autant que la vitesse. Une version plus rapide n'est utile que si elle conserve la stabilité attendue et termine les parcours autorisés. La validation interne doit donc examiner ensemble la durée, l'exactitude fonctionnelle et la qualité de la fermeture.

Une amélioration relative importante peut produire un effet très différent selon la durée d'une session. Pour une tâche courte, un démarrage plus rapide représente une part visible du temps complet. Pour une session longue consacrée à des interactions, des médias ou des téléchargements, le même gain initial devient secondaire.

La mémoire demande la même prudence. Le pic indique la marge nécessaire pendant les phases les plus coûteuses. La valeur stabilisée renseigne sur la charge que l'hôte peut conserver dans le temps. Une équipe confrontée à des arrêts pour manque de mémoire regardera d'abord le pic et la marge de sécurité. Une équipe dont les sessions restent actives longtemps suivra davantage la tendance stabilisée et la croissance au fil des cycles.

Le processeur moyen ne raconte pas non plus toute l'histoire. De brèves pointes peuvent allonger les démarrages simultanés et créer une file d'attente même si la moyenne paraît basse. Il faut donc observer les percentiles, la dispersion et la répétabilité, puis rapprocher ces mesures des délais réellement visibles dans le parcours.

Enfin, une moyenne globale peut masquer un petit groupe de tâches lentes. Conservez la distribution complète des résultats, notamment les valeurs médianes, les percentiles élevés, les échecs et les nouvelles tentatives. Une amélioration fiable doit être visible sur plusieurs répétitions et ne pas dépendre d'un seul passage favorable.

Quand retenir Standard ou évaluer Trimmed

Standard convient lorsque les sessions sont longues, interactives ou fonctionnellement variées. Il est également préférable pendant la découverte d'une nouvelle application, car l'équipe ne connaît pas encore toutes les fonctions qui seront nécessaires. Commencer avec la distribution générale réduit le risque de confondre une limite de périmètre avec un défaut du parcours.

Gardez Standard si le démarrage représente une part mineure du temps complet, si l'hôte dispose déjà d'une marge confortable ou si l'application dépend d'une fonction qui n'a pas encore été qualifiée avec Trimmed. Le coût d'un changement doit être justifié par une amélioration mesurée, pas seulement par un chiffre de référence externe.

Sur une session longue, lisez la courbe réelle de mémoire et pas la valeur de démarrage : relevez VmRSS dans /proc/<pid>/status à intervalle régulier pendant l'exécution, puis regardez VmHWM après la fermeture pour le maximum atteint. Si VmHWM dépasse nettement le VmRSS de départ, la contrainte vient de l'activité de la page et non de la phase de lancement, et changer de distribution n'y changera rien.

Standard constitue aussi un excellent groupe de contrôle. Même après l'adoption de Trimmed, conservez une petite capacité Standard avec la même version et les mêmes profils approuvés. Ce groupe permet de distinguer une régression de version, un changement du site cible, une route réseau dégradée ou un effet propre à la distribution.

Trimmed devient pertinent lorsque le parcours crée puis ferme fréquemment des contextes, que les sessions restent courtes et que le coût de préparation revient à chaque tâche. Les validations de confidentialité sur des propriétés autorisées, les contrôles de non-régression et les campagnes QA de courte durée correspondent bien à ce profil.

Une pression régulière sur le processeur ou la mémoire constitue un second signal. Si les pics obligent à réduire la concurrence, provoquent des délais ou diminuent la marge de reprise, le benchmark public donne une raison concrète d'organiser un essai. Il ne donne toutefois pas directement le nombre de sessions adapté à votre hôte. Cette valeur dépend de votre charge et doit être mesurée.

La décision doit rester réversible. Avant tout essai, définissez le paquet Standard de secours, la procédure de bascule, les responsables et les critères qui déclenchent le retour arrière. Une amélioration de performance ne doit jamais rendre la restauration incertaine.

Vérifiez les dépendances de l'image cible avant de scripter le parcours. Lancez ldd sur le binaire Trimmed et cherchez not found : un libnss3, libatk1.0-0 ou libgbm1 manquant apparaît plus tard comme un échec de lancement qui ressemble à un échec de tâche, et il se répète sur chaque hôte de la même image jusqu'à correction.

Construire une comparaison reproductible

Définir l'unité de travail. Choisissez un parcours court, autorisé et représentatif. Décrivez précisément son point de départ, ses navigations, ses interactions, sa condition de réussite et sa fermeture. Évitez une page vide ou une démonstration artificiellement légère. Une unité utile ressemble au travail de production sans utiliser de données personnelles réelles.

Préparez plusieurs classes si la production mélange des charges très différentes. Par exemple, une navigation simple, une application riche et un parcours comprenant un téléchargement peuvent avoir des budgets distincts. Ne fusionnez pas leurs résultats avant d'avoir compris leur comportement individuel.

Garder les conditions comparables. Utilisez le même hôte, la même image système, la même version BotBrowser, les mêmes profils publics compatibles, la même route approuvée et le même jeu de pages. Alternez l'ordre des passages Standard et Trimmed afin qu'une variation temporelle du réseau ou du service cible ne favorise pas toujours la même distribution.

Stabilisez les services annexes avant la mesure. Une file de tâches concurrente, une sauvegarde système ou une mise à jour automatique peut fausser les pics. Notez les événements extérieurs au lieu d'effacer silencieusement les résultats. Un essai reproductible explique ses exclusions et conserve les données brutes nécessaires à une revue.

Répéter sans saturer. Commencez avec une concurrence basse, puis augmentez par étapes. Chaque palier doit durer assez longtemps pour montrer la tendance de la mémoire, la dispersion des temps et la qualité des fermetures. Arrêtez l'augmentation lorsque la latence se dégrade, que la marge de ressources devient insuffisante ou que le résultat fonctionnel change.

Une série courte répétée vaut mieux qu'un seul essai massif. Elle permet de calculer médiane, percentiles et variabilité, puis de vérifier si l'avantage se maintient. Gardez une phase de récupération entre les séries lorsque le système en a besoin. Le but est de comparer les distributions, pas de pousser l'hôte jusqu'à l'échec.

Exécuter une QA autorisée et planifier la capacité

La validation fonctionnelle doit utiliser des environnements, comptes et propriétés pour lesquels l'équipe possède une autorisation explicite. Préférez des données synthétiques et un périmètre connu. Les journaux doivent éviter les secrets, les identifiants et le contenu personnel. Cette discipline protège à la fois les personnes, l'environnement testé et la valeur des mesures.

Pour chaque session, enregistrez un identifiant d'exécution, la version, la distribution, la classe de charge, le résultat fonctionnel et les mesures de ressources. Conservez seulement les artefacts nécessaires à la reproduction. Les captures et traces détaillées doivent suivre la politique d'accès et de rétention de l'organisation.

Validez les mêmes résultats visibles dans les deux distributions : navigation terminée, état attendu atteint, données temporaires isolées selon le plan, puis fermeture confirmée. Les différences de temps ne doivent pas masquer une page incomplète, une action omise ou un état réutilisé par erreur.

Mesurez les deux versions avec le même instrument. /usr/bin/time -v affiche en fin d'exécution Maximum resident set size (kbytes) pour l'arbre de processus créé par un lancement de navigateur ; échantillonnez ps -o rss= -p <pid> à intervalle fixe quand un seul maximum ne suffit pas. Dans ps, rss est la taille résidente et vsz la taille virtuelle, et seule la première correspond à la pression mémoire de l'hôte.

Les erreurs doivent être classées. Distinguez un problème de page, une route indisponible, un délai de l'application, une limite de ressources et une différence liée à la version. Cette classification évite d'attribuer à Trimmed une panne externe ou, inversement, de considérer une régression comme un simple aléa réseau.

La capacité utile n'est pas le maximum observé pendant quelques minutes. C'est un niveau qui respecte les objectifs de délai et de réussite tout en conservant une marge pour les pics, les nouvelles tentatives et les tâches système. Calculez séparément les budgets de processeur, de mémoire, de stockage temporaire, de descripteurs et de réseau. Pour une courbe de mémoire mesurée, des limites d'admission et un retour arrière adaptés aux sessions longues, consultez Planifier la capacité des BrowserContext, qui explique comment fixer des limites d'admission et de file réversibles.

Pour la mémoire, retenez le plus contraignant entre le pic observé et la tendance de longue durée, puis ajoutez une réserve. Pour le processeur, examinez les pointes et la durée des files d'attente. Pour le réseau, mesurez le débit, la latence et les erreurs avec la route réellement prévue. Pour le stockage, incluez journaux, téléchargements autorisés et artefacts de diagnostic retenus. Pour transformer les limites de processeur et de mémoire en budget sans les confondre avec l'identité du navigateur, consultez Limites de ressources d'un conteneur de navigateur : méthode pratique, qui présente des tableaux de budget et la surveillance de la pression.

La marge doit couvrir au minimum le démarrage simultané d'un petit groupe, une reprise après erreur et les services de l'hôte. Elle doit également tenir compte de la variation entre pages. Une capacité calculée sur la tâche la plus légère ne protège pas la production lorsque la charge réelle devient plus complexe.

Documentez la capacité par classe d'hôte et par classe de charge. Une valeur unique pour toute l'infrastructure devient vite trompeuse. Révisez le budget après une mise à jour importante de BotBrowser, du système, du profil, de l'application ou de la route réseau.

Définir le budget, l'acceptation et le retour arrière

Avant l'essai, définissez des critères d'acceptation adaptés aux deux distributions. Ils peuvent couvrir le résultat attendu, la tendance de durée, la mémoire de pointe, le processeur de pointe, la stabilité après plusieurs cycles et la qualité de la fermeture. Les critères doivent refléter votre niveau de service et votre matériel.

Une adoption raisonnable exige quatre résultats : Trimmed améliore une contrainte réellement importante, ne dégrade pas les parcours fonctionnels, reste stable pendant la durée représentative et peut être exploité avec une marge suffisante. Si un seul de ces points manque, poursuivez l'analyse ou restez sur Standard.

Ne transformez pas l'amélioration publiée en objectif obligatoire. Votre charge peut montrer un gain plus faible ou mettre en évidence un autre facteur limitant. Ce résultat reste utile : il indique où investir, par exemple dans la régulation de la file, la durée des sessions, la route réseau ou le dimensionnement de l'hôte.

Une décision prise pour une version ne doit pas être appliquée automatiquement à toutes les suivantes. Conservez un petit jeu de référence comprenant les parcours, les données synthétiques, les paramètres de l'hôte et les résultats acceptés. À chaque mise à jour, exécutez d'abord ce jeu dans un environnement isolé.

Comparez la nouvelle version à la version actuellement approuvée, puis comparez Standard et Trimmed au sein de la nouvelle version si les deux restent dans votre plan. Vérifiez les métadonnées des paquets et la compatibilité des profils avant le lancement. Ne mélangez pas des profils ou des composants provenant de versions différentes dans une mesure officielle. Pour une revue plus large des hôtes, des profils et des responsables du déploiement avant la mise en production, consultez Évaluer la cohérence du navigateur avant le déploiement, qui couvre la matrice d'hôtes et de cibles ainsi qu'une base de référence versionnée.

Déployez ensuite par étapes. Commencez par une faible part de la charge autorisée, observez les indicateurs fonctionnels et opérationnels, puis augmentez seulement après une période stable. Gardez le groupe de contrôle Standard actif pendant cette phase. Une divergence devient alors plus facile à localiser.

Consignez les arguments de lancement dans le dossier de validation. Une exécution avec --no-sandbox démarre moins de processus et retient moins de mémoire que la même exécution avec le bac à sable Chromium actif ; la comparaison n'est donc valable que si les deux côtés utilisent le même mode de bac à sable, le même jeu de dépendances et le même cycle de vie de --user-data-dir.

Le rapport de validation doit conserver la version, la distribution, l'hôte, la classe de charge, les résultats, les écarts et la décision. Il doit aussi préciser les limites de l'essai. Cette trace facilite les audits internes et évite de redécouvrir les mêmes hypothèses lors de la version suivante.

Le retour arrière fait partie du déploiement, même lorsque tous les tests sont verts. Conservez le dernier paquet Standard approuvé, les profils correspondants et une configuration prête à être remise en service. Testez la procédure avant la mise en production de Trimmed.

Définissez des déclencheurs simples : baisse du taux de réussite, hausse durable des délais, croissance anormale de la mémoire, fermeture incomplète ou différence fonctionnelle confirmée. La personne d'astreinte doit pouvoir agir sans réinterpréter tout le benchmark.

Le retour arrière doit prouver ce qu'il restaure, pas seulement où se trouve la sauvegarde. Conservez le sha256sum du binaire du navigateur et le chemin exact de --bot-profile avec la version ; après la bascule, le hachage du binaire en cours d'exécution doit correspondre à la valeur approuvée et le fichier de profil doit être celui dont la signature a été validée.

Lors d'un retour, cessez d'abord d'envoyer de nouvelles tâches vers Trimmed, laissez terminer ou fermez proprement les sessions selon la politique, puis réorientez la file vers Standard. Conservez les données minimales permettant l'analyse. N'essayez pas de compenser une régression en augmentant immédiatement la concurrence ou en supprimant des contrôles.

Après restauration, confirmez que les indicateurs reviennent à leur référence. Ouvrez ensuite une analyse distincte avec un échantillon réduit. La priorité opérationnelle est de retrouver un service connu, puis de comprendre la cause dans un environnement contrôlé.

Le benchmark public concerne Linux x64 et une charge précise. Il ne prédit pas directement les résultats d'un autre système, d'un autre matériel, d'une autre route ou d'une autre application. La direction et l'ampleur du résultat peuvent évoluer avec les versions. Elles doivent être interprétées avec leur contexte et leur date.

Trimmed vise les sessions courtes. Une validation concluante sur ce profil ne garantit pas qu'il soit préférable pour une application interactive de longue durée. Testez toutes les fonctions dont votre parcours dépend et gardez Standard lorsque le périmètre complet est nécessaire.

Le budget se lit aussi dans le cgroup v2. Relevez memory.current et memory.max dans le groupe de contrôle qui héberge le pool, et démarrez ce pool avec un plafond dur, par exemple systemd-run --scope -p MemoryMax=2G. memory.current inclut le page cache que le noyau peut récupérer : comparez-le à memory.stat avant d'appeler mémoire applicative l'écart observé.

Les gains de ressources ne remplacent pas les contrôles d'exploitation. Une file bornée, des délais adaptés, des fermetures fiables, une observabilité proportionnée et une marge de reprise restent nécessaires. Une distribution plus légère améliore un budget, mais ne corrige pas une charge non maîtrisée.

Enfin, protégez le périmètre de la QA. Utilisez seulement des systèmes autorisés, minimisez les données collectées et limitez l'accès aux artefacts. La performance n'exige ni données personnelles réelles ni scénarios hostiles.

Commencez par formuler l'hypothèse : quelle contrainte Trimmed doit-il réduire et comment cette amélioration sera-t-elle reconnue ? Construisez ensuite une référence Standard, répétez la même charge avec Trimmed, examinez la qualité et les ressources, puis décidez à partir des critères approuvés.

Si Trimmed est retenu, publiez le budget de capacité par classe de charge, la procédure de mise à jour et le plan de retour. Réévaluez ces documents lorsque la charge change. La décision reste ainsi fondée sur des preuves actuelles plutôt que sur un benchmark ancien ou une intuition.

Trimmed est distribué dans le cadre ENT Tier 3. Consultez la page Enterprise en français et les tarifs en français pour le modèle d'accès. Pour la préparation générale d'un hôte, utilisez le guide de performance et la documentation de déploiement. La méthode et son contexte restent disponibles dans le benchmark public.

BotBrowser fournit une édition Linux x64 allégée pour des comparaisons contrôlées; il ne garantit pas un débit fixe, une parité matérielle ou une performance de production.

Sources

• Documentation de performance de l'édition Trimmed
• Architecture multiprocessus de Chromium

Conclusion pratique

Standard reste le choix sûr, et Trimmed mérite une comparaison appariée seulement lorsque les sessions courtes autorisées se répètent et que l'équipe sait borner, vider et restaurer par groupe. La référence locale tient en trois mesures : pgrep -c -f chrome pour les processus d'un lancement, ps -o rss= -p <pid> pour la mémoire résidente et VmHWM pour le pic ; relevez-les sur les deux binaires avec la même révision de tâche avant de déployer sur un groupe candidat réduit.