Optimización del rendimiento del repositorio

Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Azure Repos proporciona un alto rendimiento y confiabilidad para la mayoría de los repositorios de Git. Git funciona mejor cuando los repositorios se asemejan a los proyectos de código fuente típicos: los archivos son relativamente pequeños, los cambios son incrementales y localizados, y los directorios tienen una jerarquía bien organizada. Estas condiciones permiten a Git usar la compresión delta y atravesar árboles de repositorio de forma eficaz.

Cuando un repositorio no cumple estas condiciones, Git debe leer y transferir objetos más y más grandes. Como resultado, las operaciones comunes, como la clonación, la captura y la exploración, se vuelven más lentas.

En este artículo se explica cómo analizar el estado del repositorio, identificar y resolver las causas comunes de la degradación del rendimiento y reducir la cantidad de datos transferidos durante los clones y las capturas.

Para conocer los límites de recursos que se aplican a los repositorios, consulte Límites de Git.

Análisis de estado del repositorio

Comience con el panel integrado Mantenimiento y uso . Resume el tamaño del repositorio, los recuentos de objetos, los recuentos de referencias y otras métricas. También resalta los valores que se aproximan o superan los umbrales recomendados.

Es posible que este panel no esté disponible en versiones anteriores de Azure DevOps Server. Si no lo ve, considere la posibilidad de actualizar a una versión más reciente para acceder a las métricas de mantenimiento del repositorio integradas.

Herramientas de la CLI

Para una inspección más exhaustiva, ejecute las siguientes herramientas sobre un clon completo del repositorio.

git-sizer

Se usa git-sizer para una evaluación de alto nivel del tamaño y la complejidad del repositorio. Calcula las métricas de todo el repositorio y asigna un nivel de preocupación a cada uno. Descargue la versión más reciente de la página de versiones y siga Introducción para ejecutar la herramienta y revise su salida.

Estructura del repositorio de Git

Use git repo structure como alternativa a git-sizer. Este comando experimental está diseñado para proporcionar una funcionalidad similar de forma nativa en Git estándar. Para más información, consulte la documentación del repositorio de Git.

encuesta de Git

Use git survey para el análisis a nivel de ruta. De estas herramientas de la CLI, proporciona el desglose más detallado. Clasifica los directorios principales y los archivos por recuento de objetos, tamaño en disco y tamaño inflado. El informe te ayuda a identificar los factores que más contribuyen al tamaño del repositorio y a centrarte en ellos para limpiarlos o reestructurarlos.

Este comando se incluye en Git for Windows y en la versión derivada de Git de Microsoft. La disponibilidad en otras distribuciones de Git puede variar.

Tip

El crecimiento del repositorio es más fácil de interpretar con el tiempo. Ejecute estas herramientas periódicamente y compare los resultados para realizar un seguimiento de las tendencias de crecimiento y detectar patrones problemáticos al principio.

Problemas comunes de rendimiento y mitigaciones del repositorio

Los siguientes patrones son los factores más comunes que contribuyen al crecimiento del repositorio y a la degradación del rendimiento.

Archivos grandes y actualizados con frecuencia

Los archivos grandes reducen el rendimiento de Git, ya sea texto o binario. El impacto es mayor cuando cambian con frecuencia. Dado que cada cambio normalmente vuelve a escribir una gran parte del archivo, la compresión delta deja de ser ineficaz y hace que Git almacene casi una instantánea completa para cada revisión. Como resultado, el tamaño del repositorio y el recuento de objetos crecen rápidamente.

  • Mantenga archivos grandes y actualizados con frecuencia fuera de Git. Almacénelos en Git LFS o Azure Artifacts y no confirme las salidas de compilación ni el contenido generado. Para más información, consulte Trabajar con archivos grandes en el repositorio de Git.
  • Si un archivo grande debe permanecer en Git y cambiar a menudo, divida en partes lógicas más pequeñas que se puedan versionar de forma independiente.
  • Para impedir que los nuevos archivos grandes entren en el repositorio, habilite la directiva Tamaño máximo de archivo .

Use Git LFS solo para archivos grandes que no se diferencian bien. Mover muchos archivos pequeños a LFS no mejora el rendimiento y puede empeorarlo.

Estructuras de directorio sobredimensionadas o planas

Un directorio con muchas entradas directas, tanto archivos como subdirectorios, se almacena como un objeto de árbol grande. Cualquier cambio dentro de él hace que Git escriba una nueva copia del objeto completo. Este comportamiento ralentiza las operaciones de Git y aumenta el tamaño del repositorio a lo largo del tiempo, incluso cuando los cambios son pequeños.

Mantenga el número de elementos directos en un mismo directorio en un nivel manejable. Una cantidad superior a unos cientos indica que la estructura debe reequilibrarse.

  • Organice las entradas en un diseño jerárquico equilibrado. Distribuya archivos y subdirectorios uniformemente para que ningún directorio único contenga un número excesivo de entradas directas.
  • Si necesita almacenar una gran cantidad de datos generados en el repositorio, particione en un diseño anidado, como año/mes/día.
  • Mantenga el contenido generado en un orden coherente dentro de cada archivo. Agregar o quitar una pequeña cantidad de datos solo debe afectar a las líneas relacionadas, no reordenar el resto del archivo y crear una diferencia grande. Por ejemplo, ordene siempre los elementos de lista de la misma manera.

Ramas sin usar

Demasiadas ramas de larga duración no utilizadas pueden aumentar el tamaño del repositorio y ralentizar las operaciones. Cuando se git clone un repositorio, Git descarga los objetos accesibles desde todas las ramas remotas, incluidos los archivos que nunca se fusionaron en main.

  • Elimine ramas obsoletas o sin usar periódicamente.
  • Si el repositorio necesita legítimamente un gran número de ramas, considere la posibilidad de habilitar las referencias limitadas.

Ambas acciones reducen el número de referencias que los clientes y el servidor negocian durante cada recuperación.

Importante

El almacenamiento de Azure Repos en el servidor solo permite anexar datos. Las recomendaciones de este artículo impiden un crecimiento futuro rápido, pero no reducen un repositorio que ya ha crecido. Los archivos y directorios confirmados anteriormente permanecen en el servidor. Realizar un force-push o eliminar una rama no recupera ese espacio. La única manera de quitar completamente los datos es volver a crear el repositorio y migrar solo el contenido que necesita.

Acelerar las clonaciones y las recuperaciones

Independientemente del estado de un repositorio, los clientes pueden reducir la cantidad de datos que descargan:

  • Un clon superficial limita la cantidad de historial que se recupera, lo que funciona bien para la integración continua (CI) que solo necesita los últimos commits.
  • Un clon parcial conserva el historial completo, pero descarga el contenido del archivo solo cuando sea necesario.

Para obtener más información sobre ambas opciones, consulte Clonación parcial de Git en Azure DevOps.

  • Se actualizó por última vez el