This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

Optimisation du serveur

Les développeurs de Subversion n'envisagent pas de fournir un service tel que le serveur Subversion sans pouvoir configurer finement celui-ci. Subversion n'est pas particulièrement gourmand en termes de ressources mémoire ou processeur, mais chaque service gagne à être optimisé, surtout quand l'utilisation de ce service explose[73]. Dans cette section, nous exposons quelques manières d'ajuster la configuration du serveur Subversion pour offrir encore davantage de performance et de capacité à monter en charge.

Mise en cache des données

Généralement, le travail le plus coûteux du serveur Subversion consiste à récupérer les données dans le dépôt. Subversion 1.6 essayait de réduire ce coût en introduisant la mise en cache en mémoire de certains types de données qu'il lisait dans le dépôt. Subversion 1.7 va un cran plus loin, en mettant en cache non seulement le résultat de certaines des opérations les plus coûteuses mais aussi en offrant les moyens de configurer finement la taille et le comportement du cache pour tous les serveurs.

Pour svnserve, vous pouvez spécifier la taille du cache en utilisant l'option --memory-cache-size (-M) de la ligne de commande. Vous pouvez aussi imposer à svnserve de mettre en cache le texte complet (resp. les deltas calculés) via l'option --cache-fulltexts (resp. --cache-txdeltas).

$ svnserve -d -r /chemin/vers/depots \
           --memory-cache-size 1024 \
           --cache-txdeltas yes \
           --cache-fulltexts yes
…
$

mod_dav_svn est configurable de la même manière à travers les directives de httpd.conf. Les directives SVNInMemoryCacheSize, SVNCacheFullTexts et SVNCacheTextDeltas peuvent être utilisées pour définir les caractéristiques du cache de données.

<IfModule dav_svn_module>
  # Autorise 1 Go de cache de données pour le texte et les deltas.
  SVNInMemoryCacheSize 1048576
  SVNCacheTextDeltas On
  SVNCacheFullTexts On
</IfModule>

Alors quels réglages utiliser ? Vous devez déjà prendre en compte les ressources dont dispose votre serveur. Pour obtenir un gain avec le cache, vous devrez probablement avoir un cache capable de contenir tous les fichiers dont les accès sont réguliers dans votre dépôt (par exemple, la sous-arborescence trunk de votre projet).

[Astuce] Astuce

Spécifier une taille de cache de 0 désactive le mécanisme de cache évolué et entraine l'utilisation du mécanisme de cache introduit par la version 1.6 de Subversion.

[Note] Note

Actuellement, seuls les dépôts utilisant le magasin de données FSFS mettent en œuvre le mécanisme de cache.

Compression des données sur le réseau

Compresser les données qui transitent sur le réseau peut réduire significativement la taille des données transmises, au détriment d'une consommation CPU sur le serveur et le client. En fonction de la capacité du processeur de votre serveur, des données que récupèrent vos clients sur vos serveurs et de la bande passante disponible sur le réseau, il peut être avantageux d'ajuster le taux de compression défini sur votre serveur avant d'envoyer les données sur le réseau. Pour vous aider dans cette phase de configuration, Subversion 1.7 propose l'option --compression (-c) pour svnserve et la directive SVNCompressionLevel pour mod_dav_svn. Les deux acceptent une valeur entière comprise entre 0 et 9 (inclus), 9 offrant la plus grande compression et 0 désactivant toute compression.

Par exemple, sur un réseau local (LAN) Gigabit, il n'est pas pertinent de compresser les données (qui doivent être aussi décompressées par les clients) car le réseau est tellement rapide que les utilisateurs ne verront pas le gain de diminuer la charge réseau. En revanche, les serveurs dont les clients sont connectés via des connexions bas débit seront bien inspirés de minimiser les flux réseau vers ces clients.



[73] Dans le cas de Subversion, l'explosion est due, bien sûr, à son nom très cool. Et aussi à sa popularité, sa fiabilité, sa facilité d'utilisation, …