bundle-uri est une nouvelle fonctionnalité de Git qui télécharge des fichiers mis en cache pour préremplir les données d’un projet, puis réduit la complexité des opérations de fetch avec le serveur- En général, la commande
git clone négocie avec le serveur pour télécharger les données nécessaires → cela peut être inefficace
bundle-uri récupère des données initiales mises en cache depuis un CDN, puis ne met à jour que l’état le plus récent depuis le serveur → gain de temps possible
Le clonage devient-il plus rapide ?
Oui ? - Cela peut l’être
- Avec l’option de fichier local, la vitesse de clonage devient très élevée
- Sur une VM avec un système de fichiers monté, ou via un fichier bundle dans un cache cloud, la synchronisation peut être plus rapide
Non ? - Cela peut être plus lent
- Recevoir les mêmes données depuis un CDN semblait devoir être plus rapide, mais c’était en réalité plus lent
- Résultat de l’expérience : le clonage avec bundle était plus lent qu’un clonage classique
- Clonage classique : 2 min 36 s
- Clonage avec bundle : 3 min 20 s
- Un problème faisait que des objets déjà reçus dans le bundle étaient téléchargés à nouveau
Peut-être ? - C’est possible
- Le problème vient du fait que Git ne lit dans le fichier bundle que
refs/heads (les références de branches)
- Comme les autres références sont ignorées, des données supplémentaires sont téléchargées depuis le serveur
- En modifiant le code de Git pour copier toutes les références, la vitesse de clonage s’améliore
- Temps de clonage après modification : 2 min 19 s (plus rapide que les 2 min 36 s initiaux)
- Nombre d’objets téléchargés en plus : 43 877 (environ 1 % du total)
Méthode de correction et application du patch
- Correction de la partie du code
bundle-uri.c de Git qui ignore les références autres que refs/heads
- Après modification, toutes les références sont copiées → amélioration de la vitesse de clonage
- Il s’agissait d’un patch minimal composé d’une modification de 6 caractères
Faut-il utiliser cette fonctionnalité ?
Possiblement - Cela peut aider
- Sur des plateformes comme GitHub ou GitLab, cela présente un gros avantage en réduisant la charge CPU côté serveur
- Le serveur n’a pas à calculer directement le packfile, le traitement peut être pris en charge par le CDN → économie de ressources serveur
- Cas où cela peut aussi être utile pour les utilisateurs individuels :
- lorsqu’il faut répéter de gros clonages sur un serveur Git interne
- lorsqu’un système CI/CD nécessite des clonages complets répétés
En pratique, il y a de fortes chances que cela devienne imposé
- Dans le protocole Git récent, le serveur peut fournir au client une URL de bundle
- Si le serveur fournit l’URL d’un fichier bundle, le client le télécharge automatiquement puis lance la synchronisation
- Si cette fonctionnalité est activée sur GitHub ou ailleurs, les utilisateurs n’auront guère le choix
Conclusion
- L’usage de fichiers bundle peut accélérer le clonage, mais à cause de la manière dont Git les traite, cela peut d’abord le ralentir
- En modifiant le code de Git pour améliorer la gestion des références, la vitesse de clonage progresse
- Si GitHub, GitLab et d’autres adoptent cette fonctionnalité, il est probable qu’elle soit utilisée automatiquement côté client
Aucun commentaire pour le moment.