L'auteur du document, dont nous publions aujourd'hui la traduction, indique qu'à la mi-septembre 2019, il a enfin achevé le projet sur lequel il travaille depuis un an. L'objectif de ce projet était de réduire la taille du manifeste requis pour initialiser le pipeline JavaScript asynchrone Wikipedia. À savoir, la taille du manifeste était de 36 Ko. Il devait tenir dans moins de 28 Ko, ce qui correspond à deux fragments de 14 kilo-octets de la séquence de paquets Internet.
Le résultat de ce projet a été une économie quotidienne de 4,3 téraoctets de trafic.
Au début, la taille du manifeste dépassait 36 Ko, et après optimisation, sa taille est devenue inférieure à 28 KoLe graphique montre une diminution progressive de la taille du manifeste. Nous parlons de données compressées (c'est-à-dire que c'est la charge nette sur le réseau, qui crée le transfert de ces données du serveur vers le navigateur).
Processus d'optimisation
Le manifeste d'initialisation est représenté par des données qui ne sont pas faciles à optimiser. La majeure partie de son code n'est pas quelque chose comme la logique fonctionnelle qui peut être optimisée par des moyens traditionnels. Au lieu de cela, presque tout le manifeste est représenté par des données pures. Ces données sont générées automatiquement par le système de distribution de contenu
ResourceLoader . Il s'agit d'un registre de bundles de modules. Wikipedia utilise le système ResourceLoader pour travailler avec JavaScript, CSS et les ressources textuelles.
Le registre comprend des métadonnées pour toutes les fonctionnalités frontales déployées sur Wikipedia. Le manifeste répertorie les noms des bundles, leurs versions actuelles, leurs dépendances sur d'autres bundles similaires sont décrits ici.
J'ai commencé par chercher du code qui n'a jamais été utilisé en pratique (
T202154 ). Cela comprenait la recherche de morceaux de code incomplets ou oubliés liés aux fonctionnalités héritées. Le code inutilisé a été immédiatement supprimé pour assurer la compatibilité avec les navigateurs qui n'ont plus réussi notre test, ce qui a assuré leur inclusion dans le groupe des navigateurs modernes (
Grade A ). J'ai également préparé un
document sur les performances de chargement des pages. Ce document a servi de référence, permettant aux développeurs de comprendre l'impact des changements de différents types sur les différentes étapes du processus de chargement des pages.
Réduisez le nombre de modules
L'étape suivante a été de collaborer avec les équipes d'ingénierie de la Fondation Wikimedia et de Wikimedia Deutschland. Nous devions découvrir quelles fonctionnalités du système utilisaient un nombre excessif de modules. Par exemple, après avoir compris cela, il serait possible de combiner des faisceaux précédemment dispersés à partir desquels une certaine fonctionnalité a été construite. De tels faisceaux, même dans un état dispersé, sont toujours chargés ensemble. Cela conduirait au fait qu'il y aurait moins de points finaux dans le système dont les métadonnées devraient être stockées dans le registre formé par ResourceLoader.
Voici quelques points intéressants sur l'application de cette approche d'optimisation:
- L'extension WikiEditor compte désormais 11 modules de moins qu'auparavant. 31 autres modules ont été supprimés de UploadWizard.
- Lors de l'optimisation du programme ContentTranslation, 24 modules ont été combinés.
- Le projet MobileFrontend combine 25 modules.
- 20 modules supprimés de RevisionSlider et TwoColConflict.
Il est également très important que le client Wikidata pour Wikipedia ait été optimisé. Cette partie de l'œuvre elle-même était un projet épique (
T203696 ). Au départ, 248 modules individuels étaient responsables de la mise en œuvre de cette fonctionnalité. Après avoir réussi à nous débarrasser de plus de 200 modules, il n'y en avait plus que 42.
Le diagramme ci-dessus montre les petites améliorations qui ont été apportées au projet au cours de l'année. Tous nous ont rapprochés de l'objectif. Je voudrais surtout noter deux grosses baisses de la taille du manifeste. Une telle chute s'est produite au cours de la première semaine d'août. C'est alors qu'une version améliorée de Wikidata a été déployée. La deuxième baisse de taille peut être observée à la toute fin du graphique. C'est arrivé à la mi-septembre. J'aimerais maintenant vous parler de lui.
Réduisez la taille des métadonnées
L'amélioration du manifeste qui s'est produite à la mi-septembre a été rendue possible par deux changements globaux visant à une organisation des données plus intelligente.
La première amélioration est que, auparavant, les métadonnées du schéma d'extension
EventLogging faisaient partie du manifeste principal. Ce mécanisme a été refactorisé, de sorte que les métadonnées de schéma soient désormais incluses dans le bundle JS du client EventLogging. En conséquence, la contribution à la taille du manifeste effectuée précédemment par EventLogging a été réduite de plus de 90%. Cela signifie que le chemin critique contient désormais 2 Ko de données en moins! Cela signifiait en outre que l'extension des capacités d'EventLogging n'entraînait plus d'augmentation de la taille du manifeste. Lors de l'assemblage de ces ensembles, une nouvelle fonctionnalité de ResourceLoader,
Package Files, a été utilisée . Cette fonctionnalité a été introduite en février 2019, l'une des raisons de son intérêt est qu'elle pourrait aider à réduire le nombre de modules dans le registre. Les fichiers de package simplifient considérablement le processus de combinaison des données générées et du code JavaScript dans un seul module.
La deuxième amélioration s'est produite lorsque nous avons réduit la taille moyenne de chaque entrée de registre (
T229245 ). Le manifeste contient deux entrées pour chaque module. Il s'agit du nom du module et de l'identifiant (ID) de sa version. L'identifiant de version nécessitait auparavant 7 octets de données. Après avoir réfléchi
au paradoxe de l'anniversaire dans le contexte de ResourceLoader, nous avons décidé que le spectre de probabilité des ID de version pouvait être réduit en toute sécurité de 78 milliards à «seulement» 60 millions. Des détails à ce sujet peuvent être trouvés dans les
commentaires du code. Mais, pour résumer cette amélioration, nous pouvons dire que cela nous a permis d'économiser 2 octets dans la description de chacun des 1 100 modules qui sont encore dans le registre. En conséquence, la taille du manifeste a été réduite de 2 à 3 Ko supplémentaires.
Ci-dessous est un fragment agrandi du diagramme montrant les derniers jours de fonctionnement (ces indicateurs sont tirés du système de surveillance synthétique, des données non compressées sont utilisées ici).
Redimensionnement du manifeste au stade final d'un projetLe changement a été capturé par le système de surveillance ResourceLoader. La capture d'écran montre le panneau de
taille du manifeste de démarrage situé dans une instance publique de Grafana. Ici, vous pouvez voir que la taille du flux de données non compressé a diminué de 2,8 Ko.
Le déploiement du système, qui a eu lieu à la mi-septembre, a permis d'atteindre l'objectif initial, qui était de compresser le manifeste à une taille ne dépassant pas 28 Ko. La mise en œuvre de ce projet à grande échelle a conduit au fait que le manifeste d'initialisation a été réduit de 9 Ko (nous parlons de données compressées). Il y a un an, cette taille était de 36,2 Ko, et après l'achèvement du projet, elle était déjà de 27,2 Ko.
Environ 363 000 pages vues sont générées chaque minute sur Wikipédia et les projets connexes. En une heure - 21 millions et 800 mille. Quotidien - 523 millions (
voici les statistiques sur les pages vues). Cette version du système, qui a été déployée à la mi-septembre, a permis d'économiser environ 1,4 téraoctets de trafic par jour. Et si vous comparez ce qui est aujourd'hui à ce qu'il était il y a un an, il s'avère que 4,3 téraoctets de trafic sont désormais enregistrés quotidiennement.
Et ensuite?
Nous avons réussi à adapter le manifeste d'initialisation Wikipedia de 28 Ko. C'est la taille qui a été choisie car c'est la plus petite qui soit un multiple de 14 Kb. Des données de cette taille peuvent être placées dans des fragments de la
séquence de paquets Internet transmis au navigateur.
Nous sommes maintenant confrontés à une nouvelle tâche: ne pas abandonner de postes. Au cours de la dernière année, j'ai suivi de près le
manifeste . Je l'ai fait afin de garantir nos succès et de découvrir les problèmes potentiels qui nous font reculer. Au final, j'ai automatisé ce processus en utilisant le
tableau de bord public
Grafana .
Si vous croyez à ce panneau, alors nous avons encore de nombreuses opportunités pour améliorer le packaging du code, et pour résoudre des problèmes encore plus forts que maintenant, faciliter la création de bundles. J'espère que ces améliorations à venir nous seront utiles, mais pour l'instant nous travaillons sur de nouvelles fonctionnalités du système, tout en nous efforçant de respecter les exigences de niveau de performance du projet.
Chers lecteurs! Avez-vous déjà participé à l'optimisation de grands projets Internet?
