Performances SVN après de nombreuses révisions
Mon projet utilise actuellement un dépôt svn qui gagne plusieurs centaines de nouvelles révisions par jour. Le référentiel réside sur un serveur Win2k3 et est servi via Apache/mod_dav_svn.
Je crains maintenant qu'avec le temps, les performances se dégradent en raison de trop de révisions.
Cette peur est-elle raisonnable?
Nous prévoyons déjà de passer à la version 1.5, donc avoir des milliers de fichiers dans un répertoire ne sera pas un problème à long terme.
Subversion on stocke le delta (différences), entre 2 révisions, donc cela permet d'économiser BEAUCOUP d'espace, surtout si vous ne validez que du code (texte) et pas de binaires (images et documents).
Est-ce à dire que pour extraire la révision 10 du fichier foo.baz, svn prendra la révision 1 puis appliquera les deltas 2-10?
Quel type de repo avez-vous? FSFS ou BDB?
(Supposons FSFS pour l'instant, car c'est la valeur par défaut.)
Dans le cas de FSFS, chaque révision est stockée sous forme de diff par rapport à la précédente. Donc, on pourrait penser que oui, après de nombreuses révisions, ce serait très lent.
Mais ce n'est pas le cas. FSFS utilise ce qu'on appelle des "sauts de deltas" pour éviter d'avoir à faire trop de recherches sur les tours précédents.
(Donc, si vous utilisez un dépôt FSFS, la réponse de Brad Wilson est fausse.)
Dans le cas d'un dépôt BDB, la révision HEAD (dernière)) est en texte intégral, mais les révisions antérieures sont construites comme une série de différences par rapport à la tête. Cela signifie que les révolutions précédentes doivent être recalculé après chaque validation.
Pour plus d'informations: http://svn.Apache.org/repos/asf/Subversion/trunk/notes/skip-deltas
P.S. Notre dépôt est d'environ 20 Go, avec environ 35 000 révisions, et nous n'avons remarqué aucune dégradation des performances.
Subversion stocke la version la plus récente en texte intégral, avec des différences rétrospectives. Cela signifie que les mises à jour de la tête sont toujours rapides, et ce que vous payez progressivement est de plus en plus ancien.
Personnellement, je n'ai pas traité de référentiels Subversion avec des bases de code supérieures à 80K LOC pour le projet réel. Le plus grand référentiel que j'ai réellement eu était d'environ 1,2 concerts, mais cela comprenait toutes les bibliothèques et utilitaires que le projet utilise.
Je ne pense pas que l'utilisation au jour le jour sera affectée autant, mais tout ce qui doit passer en revue les différentes révisions pourrait ralentir un peu. Cela peut même ne pas être perceptible.
Maintenant, du point de vue de l'administrateur système, il y a quelques choses qui peuvent vous aider à minimiser les goulots d'étranglement des performances. Étant donné que Subversion est principalement un système basé sur des fichiers, vous pouvez le faire:
- Mettez les référentiels réels dans un lecteur différent
- Assurez-vous qu'aucune application de verrouillage de fichier, autre que svn, ne fonctionne sur le lecteur ci-dessus
- Faites les disques au moins 7 500 tr/min. Vous pouvez essayer d'obtenir 10 000 tr/min, mais cela peut être exagéré
- Mettez à jour le LAN en gigabit, si tout le monde est dans le même bureau.
Cela peut être exagéré pour votre situation, mais c'est ce que j'ai l'habitude de faire pour d'autres applications gourmandes en fichiers.
Si vous avez déjà dépassé Subversion, alors Perforce sera votre prochaine étape. C'est de loin l'application de contrôle de source la plus rapide pour les très gros projets.
Nous exécutons un serveur Subversion avec des gigaoctets de code et des binaires, et c'est jusqu'à plus de vingt mille révisions. Aucun ralentissement pour le moment.
Je ne pense pas que notre Subversion ait ralenti en vieillissant. Nous avons actuellement plusieurs téraoctets de données, principalement binaires. Nous vérifions/nous engageons quotidiennement jusqu'à 50 Go de données. Au total, nous avons actuellement 50000 révisions. Nous utilisons FSFS comme type de stockage et nous interfaçons soit directement SVN: (serveur Windows) soit via Apache mod_dav_svn (Gentoo Linux Server).
Je ne peux pas confirmer que cela ralentit au fil du temps, car nous avons configuré un serveur propre pour la comparaison des performances auquel nous pourrions comparer. Nous n'avons PAS pu mesurer une dégradation importante.
Cependant, je dois dire que notre Subversion est exceptionnellement lent par défaut et, évidemment, c'est Subversion lui-même que nous avons essayé avec un autre système informatique.
Pour des raisons inconnues, Subversion semble être complètement limité par le CPU du serveur. Nos taux de paiement/validation sont limités entre 15 et 30 mégaoctets/s par client, car un cœur de processeur du serveur est alors complètement utilisé. C'est la même chose pour un référentiel presque vide (1 GigaByte, 5 révisions) que pour notre serveur complet (~ 5 TeraByte, 50000 révisions). Un réglage comme le réglage de la compression sur 0 = désactivé n'a pas amélioré cela.
Notre High Bandwith (délivre ~ 1 GigaByte/s) FC-Array est inactif, les autres cœurs sont inactifs et le réseau (actuellement 1 GigaBit/s pour les clients, 10 GigaBits/s pour le serveur) est également inactif. D'accord, pas vraiment au ralenti, mais si seulement 2-3% de la capacité disponible est utilisée, je l'appelle au ralenti.
Ce n'est pas vraiment amusant de voir tous les composants tourner au ralenti et nous devons attendre que nos copies de travail soient récupérées ou validées. Fondamentalement, je n'ai aucune idée de ce que fait le processus serveur en consommant entièrement un cœur de processeur tout le temps lors de la validation/validation.
Cependant, j'essaie juste de trouver un moyen de régler Subversion. Si cela n'est pas possible, nous devrons peut-être passer à un autre système.
Par conséquent: Réponse: Aucun SVN ne dégrade pas les performances, il est initialement lent.
Bien sûr, si vous n'avez pas besoin de performances (élevées), vous n'aurez pas de problème. Btw. tout ce qui précède s'applique à la dernière version stable de subversioon 1.7
Subversion ne stocke que le delta (différences), entre 2 révisions, donc cela permet d'économiser BEAUCOUP d'espace, surtout si vous ne validez que du code (texte) et pas de binaires (images et documents).
De plus, j'ai vu beaucoup de très gros projets utilisant svn et je ne me suis jamais plaint des performances.
Peut-être que vous vous inquiétez des heures de départ? alors je suppose que ce serait vraiment un problème de réseau.
Oh, et j'ai travaillé sur des référentiels CVS avec 2 Go + de trucs (code, imgs, docs) et je n'ai jamais eu de problème de performances. Étant donné que svn est une grande amélioration par rapport aux CV, je ne pense pas que vous devriez vous en inquiéter.
J'espère que cela vous aidera à vous détendre un peu;)
Les seules opérations susceptibles de ralentir sont les éléments qui lisent les informations de plusieurs révisions (par exemple, SVN Blame).