Ottimizzare le prestazioni del repository

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Azure Repos offre prestazioni elevate e affidabilità per la maggior parte dei repository Git. Git offre prestazioni ottimali quando i repository sono simili a progetti di codice sorgente tipici: i file sono relativamente piccoli, le modifiche sono incrementali e localizzate e le directory hanno una gerarchia ben organizzata. Queste condizioni consentono a Git di usare la compressione differenziale e attraversare alberi del repository in modo efficiente.

Quando un repository non soddisfa queste condizioni, Git deve leggere e trasferire oggetti più grandi e più grandi. Di conseguenza, le operazioni comuni, ad esempio la clonazione, il recupero e l'esplorazione, diventano più lente.

Questo articolo illustra come analizzare l'integrità del repository, identificare e risolvere le cause comuni della riduzione delle prestazioni e ridurre la quantità di dati trasferiti durante i cloni e i recupero.

Per i limiti delle risorse applicabili ai repository, vedere Limiti git.

Analisi dell'integrità del repository

Inizia con il pannello Stato e utilizzo integrato. Riepiloga le dimensioni del repository, i conteggi degli oggetti, i conteggi dei riferimenti e altre metriche. Evidenzia anche i valori che si avvicinano o superano le soglie consigliate.

Questo pannello potrebbe non essere disponibile nelle versioni precedenti di Azure DevOps Server. Se non viene visualizzato, è consigliabile eseguire l'aggiornamento a una versione più recente per accedere alle metriche di integrità predefinite del repository.

Strumenti di interfaccia della riga di comando

Per un'ispezione più approfondita, eseguire gli strumenti seguenti su un clone completo del repository.

git-sizer

Usare git-sizer per una valutazione generale delle dimensioni e della complessità del repository. Calcola le metriche a livello di repository e assegna un livello di preoccupazione a ognuno di essi. Scaricare la versione più recente dalla pagina delle versioni e seguire Introduzione per eseguire lo strumento ed esaminarne l'output.

Struttura del repository Git

Usare git repo structure come alternativa a git-sizer. Questo comando sperimentale è progettato per fornire funzionalità simili in modo nativo in Git mainstream. Per altre informazioni, vedere la documentazione del repository Git.

sondaggio git

Usare git survey per l'analisi a livello di percorso. Tra questi strumenti CLI, è quello che fornisce la suddivisione più dettagliata. Classifica le directory e i file principali in base al numero di oggetti, alle dimensioni su disco e alle dimensioni gonfiate. Il report consente di identificare gli elementi che contribuiscono maggiormente alle dimensioni del repository e di intervenire su di essi per la pulizia o la riorganizzazione.

Questo comando è incluso in Git per Windows e nel fork di Git di Microsoft. La disponibilità in altre distribuzioni Git può variare.

Suggerimento

L'aumento del repository è più semplice da interpretare nel tempo. Eseguire periodicamente questi strumenti e confrontare i risultati per tenere traccia delle tendenze di crescita e rilevare i modelli problematici in anticipo.

Problemi comuni di prestazioni e mitigazioni del repository

I seguenti schemi sono tra i fattori più comuni che contribuiscono all'aumento delle dimensioni dei repository e al degrado delle prestazioni.

File di grandi dimensioni e aggiornati di frequente

I file di grandi dimensioni riducono le prestazioni git, sia che si tratti di testo o binario. L'impatto è maggiore quando cambiano di frequente. Poiché ogni modifica in genere riscrive una grande parte del file, la compressione differenziale diventa inefficace e fa sì che Git archivii quasi uno snapshot completo per ogni revisione. Di conseguenza, le dimensioni del repository e il numero di oggetti aumentano rapidamente.

  • Tieni fuori da Git i file di grandi dimensioni e aggiornati frequentemente. Archiviarli in Git LFS o Azure Artifacts e non eseguire il commit degli output di compilazione o del contenuto generato. Per altre informazioni, vedere Usare file di grandi dimensioni nel repository Git.
  • Se un file di grandi dimensioni deve rimanere in Git e viene modificato spesso, suddividilo in parti logiche più piccole che possono essere gestite con controllo di versione in modo indipendente.
  • Per interrompere l'immissione di nuovi file di grandi dimensioni nel repository, abilitare il criterio Dimensioni massime file .

Usa Git LFS solo per file di grandi dimensioni che non si prestano bene al diff. Lo spostamento di molti file di piccole dimensioni in LFS non migliora le prestazioni e può peggiorare.

Strutture di directory sovradimensionate o piatte

Una directory con molti elementi contenuti direttamente, sia file che sottodirectory, viene memorizzata come un unico grande oggetto albero. Qualsiasi modifica al suo interno rende Git scrivere una nuova copia dell'intero oggetto. Questo comportamento rallenta le operazioni Git e aumenta le dimensioni del repository nel tempo, anche quando le modifiche sono ridotte.

Mantieni gestibile il numero di elementi presenti in una singola directory. Un conteggio superiore a poche centinaia è un segno che la struttura deve essere ribilanciata.

  • Organizza le voci in una struttura gerarchica ed equilibrata. Distribuire file e sottodirectory in modo uniforme in modo che nessuna singola directory contenga un numero eccessivo di voci dirette.
  • Se è necessario archiviare una grande quantità di dati generati nel repository, partizionarli in un layout annidato, ad esempio anno/mese/giorno.
  • Mantenere il contenuto generato in un ordine coerente all'interno di ogni file. L'aggiunta o la rimozione di una piccola quantità di dati deve influire solo sulle righe correlate, non riordinare il resto del file e creare una diff di grandi dimensioni. Ad esempio, ordinare sempre gli elementi dell'elenco nello stesso modo.

Rami inutilizzati

Troppi rami inutilizzati di lunga durata possono aumentare le dimensioni del repository e rallentare le operazioni. Quando si esegue git clone un repository, Git scarica oggetti raggiungibili da ogni ramo remoto, inclusi i file che non sono mai stati uniti in main.

  • Eliminare regolarmente rami non aggiornati o inutilizzati.
  • Se il repository necessita legittimamente di un numero molto elevato di rami, considera di abilitare Limited Refs.

Entrambe le azioni riducono il numero di ref che i client e il server negoziano durante ogni operazione di fetch.

Importante

L'archiviazione di Azure Repos sul server è di tipo solo aggiunta. Le raccomandazioni contenute in questo articolo impediscono una rapida crescita futura, ma non riducono un repository già cresciuto. I file e le directory di cui è stato eseguito il commit in precedenza rimangono nel server. Il push forzato o l'eliminazione di un ramo non recupera lo spazio. L'unico modo per rimuovere completamente i dati consiste nel ricreare il repository ed eseguire la migrazione solo del contenuto necessario.

Accelerare i cloni e i recuperi

Indipendentemente dal livello di integrità di un repository, i client possono ridurre la quantità di dati scaricati:

  • Un clone parziale limita la quantità di cronologia scaricata, il che funziona bene per la CI che ha bisogno solo dei commit più recenti.
  • Un clone parziale mantiene la cronologia completa, ma scarica il contenuto del file solo quando necessario.

Per altre informazioni su entrambe le opzioni, vedere Git Partial Clone in Azure DevOps.

  • Ultimo aggiornamento: