Optimiser les performances du référentiel

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Azure Repos offre des performances et une fiabilité élevées pour la plupart des référentiels Git. Git fonctionne le mieux lorsque les référentiels ressemblent à des projets de code source classiques : les fichiers sont relativement petits, les modifications sont incrémentielles et localisées, et les répertoires ont une hiérarchie bien organisée. Ces conditions permettent à Git d’utiliser efficacement la compression delta et de parcourir efficacement les arborescences de référentiels.

Lorsqu’un référentiel ne remplit pas ces conditions, Git doit lire et transférer davantage d’objets, et des objets plus volumineux. Par conséquent, les opérations courantes, telles que le clonage, la récupération et la navigation, deviennent plus lentes.

Cet article explique comment analyser l’intégrité du référentiel, identifier et résoudre les causes courantes de la dégradation des performances, et réduire la quantité de données transférées pendant les clones et les extractions.

Pour connaître les limites de ressources qui s’appliquent aux référentiels, consultez les limites Git.

Analyse de l’état du dépôt

Commencez par le panneau d’intégrité et d’utilisation intégré. Il récapitule la taille du référentiel, le nombre d’objets, les nombres de références et d’autres métriques. Il met également en évidence les valeurs qui approchent ou dépassent les seuils recommandés.

Ce panneau peut ne pas être disponible dans les versions antérieures de Azure DevOps Server. Si cette option n’apparaît pas, envisagez de passer à une version plus récente pour accéder aux métriques intégrées sur l’état du dépôt.

Outils CLI

Pour une inspection plus approfondie, exécutez les outils suivants sur un clone complet du référentiel.

git-sizer

Utiliser git-sizer pour une évaluation générale de la taille et de la complexité du référentiel. Il calcule les métriques à l’échelle du référentiel et affecte un niveau de préoccupation à chacun d’eux. Téléchargez la dernière version depuis la page des versions et suivez Prise en main pour exécuter l’outil et examiner le résultat produit.

Structure du dépôt git

Utiliser git repo structure comme alternative à git-sizer. Cette commande expérimentale est conçue pour fournir des fonctionnalités similaires en mode natif dans Git standard. Pour plus d’informations, consultez la documentation sur le dépôt Git.

enquête sur Git

Utiliser git survey pour l’analyse au niveau du chemin d’accès. De ces outils CLI, il fournit la répartition la plus détaillée. Il classe les principaux répertoires et fichiers par nombre d’objets, taille sur disque et taille gonflée. Le rapport vous aide à identifier les plus grands contributeurs à la taille du référentiel et à les cibler pour le nettoyage ou la restructuration.

Cette commande est incluse dans Git for Windows et dans le fork de Git de Microsoft. La disponibilité dans d’autres distributions Git peut varier.

Tip

La croissance du référentiel est plus facile à interpréter au fil du temps. Exécutez ces outils régulièrement et comparez les résultats pour suivre les tendances de croissance et détecter les modèles problématiques au début.

Problèmes courants de performance des référentiels et mesures d’atténuation

Les modèles suivants sont les contributeurs les plus courants à la croissance du référentiel et aux performances dégradées.

Fichiers volumineux et fréquemment mis à jour

Les fichiers volumineux réduisent les performances Git, qu’ils soient texte ou binaire. L’impact est le plus important lorsqu’ils changent fréquemment. Étant donné que chaque modification réécrit généralement une grande partie du fichier, la compression delta devient inefficace et provoque le stockage d’un instantané presque complet pour chaque révision. Par conséquent, la taille du référentiel et le nombre d’objets augmentent rapidement.

  • Gardez les fichiers volumineux et fréquemment mis à jour hors de Git. Stockez-les dans Git LFS ou Azure Artifacts et ne validez pas les sorties de build ou le contenu généré. Pour plus d’informations, consultez Utiliser des fichiers volumineux dans votre dépôt Git.
  • Si un fichier volumineux doit rester dans Git et qu’il change souvent, fractionnez-le en éléments logiques plus petits qui peuvent être versionnés indépendamment.
  • Pour empêcher les nouveaux fichiers volumineux d’entrer dans le référentiel, activez la stratégie de taille de fichier maximale .

Utilisez Git LFS uniquement pour les fichiers volumineux pour lesquels les différences sont peu exploitables. Le déplacement de nombreux petits fichiers dans LFS n’améliore pas les performances et peut le rendre pire.

Structures de répertoires surdimensionnées ou plates

Un répertoire avec de nombreuses entrées directes, à la fois des fichiers et des sous-répertoires, est stocké en tant qu’objet d’arborescence volumineux. Toute modification à l’intérieur oblige Git à écrire une nouvelle copie de l’objet entier. Ce comportement ralentit les opérations Git et augmente la taille du référentiel au fil du temps, même lorsque les modifications sont petites.

Conservez le nombre d’entrées directes dans n’importe quel répertoire unique gérable. Un nombre supérieur à quelques centaines est un signe que la structure doit être rééquilibrée.

  • Organisez les entrées dans une disposition hiérarchique équilibrée. Distribuez uniformément des fichiers et des sous-répertoires afin qu’aucun répertoire unique ne contienne un nombre excessif d’entrées directes.
  • Si vous devez stocker une grande quantité de données générées dans le référentiel, partitionnez-la dans une disposition imbriquée telle que l’année/le mois/jour.
  • Conservez le contenu généré dans un ordre cohérent dans chaque fichier. L’ajout ou la suppression d’une petite quantité de données doit affecter uniquement les lignes associées, et non réorganiser le reste du fichier et créer un grand écart. Par exemple, triez toujours les éléments de liste de la même façon.

Branches inutilisées

Un trop grand nombre de branches de longue durée inutilisées peuvent augmenter la taille du référentiel et ralentir les opérations. Lorsque vous git clone avez un dépôt, Git télécharge des objets accessibles à partir de chaque branche distante, y compris les fichiers qui n’ont jamais été fusionnés dans main.

  • Supprimez régulièrement les branches obsolètes ou inutilisées.
  • Si votre référentiel a légitimement besoin d’un très grand nombre de branches, envisagez d’activer les références limitées.

Les deux actions réduisent le nombre de références que les clients et le serveur négocient pendant chaque extraction.

Important

Le stockage Azure Repos est ajouté uniquement sur le serveur. Les recommandations de cet article empêchent une croissance future rapide, mais elles ne réduisent pas un référentiel qui a déjà augmenté. Les fichiers et répertoires précédemment validés restent sur le serveur. L’envoi forcé ou la suppression d’une branche ne récupère pas cet espace. La seule façon de supprimer complètement les données consiste à recréer le référentiel et à migrer uniquement le contenu dont vous avez besoin.

Accélérer les clonages et les fetchs

Quel que soit l’intégrité d’un référentiel, les clients peuvent réduire la quantité de données qu’ils téléchargent :

  • Un clone superficiel limite la quantité d’historique récupérée, ce qui fonctionne bien pour la CI qui n’a besoin que des derniers commits.
  • Un clone partiel conserve l’historique complet, mais télécharge le contenu du fichier uniquement si nécessaire.

Pour plus d’informations sur les deux options, consultez Clone partiel Git dans Azure DevOps.

  • Dernière mise à jour :