Amélioration des performances

Considérations matérielles

L’architecture physique d’un serveur est bien entendu le premier élément à considérer pour permettre à l’application de fonctionner dans les meilleures conditions possible. Il faut donc s’assurer de respecter les recommandations préconisées par l’éditeur de l’application... même si celles-ci sont la plupart du temps en deçà de la réalité, car réalisées dans des environnements de test, bien loin des contraintes d’un réel environnement de production.

1. La mémoire ou RAM

C’est bien entendu l’élément essentiel qui permettra de résoudre instantanément les problèmes de performance de l’application LDAP, car comme pour n’importe quelle autre application, plus la quantité d’informations de l’annuaire y sera stockée, meilleures seront les performances... En effet, en règle générale les problèmes de performance se situent au niveau de l’accès aux disques lors des actions de lecture/écriture (généralement connu sous le terme I/O). Ainsi, outre l’aspect quantitatif où l’achat de mémoire pourrait suffire jusqu’à l’atteinte de la limite supportée par le processeur ou la carte mère...

Au niveau du processus "slapd"

1. Paramétrage des threads

Afin d’optimiser le temps de traitement des requêtes LDAP et par conséquent d’augmenter le rendement de requêtes traitées, OpenLDAP offre la possibilité de définir, au travers de la configuration de son service/processus "slapd", un nombre de "thread" calculé en fonction du nombre de CPU "réel" du système et de la règle de quatre thread par CPU.

Par exemple, sur un serveur possédant quatre CPU "logiques" pour deux CPU "réels", alors il faudra définir le nombre de thread à 8. Il s’agit ici d’une valeur maximale pour l’optimisation des requêtes LDAP de type lecture, non approprié pour des requêtes en écriture.

Cela signifie donc que plus il y aura de thread définis par CPU, plus les opérations de lecture seront lentes et celles de type écriture seront rapides ; et inversement. Ainsi, le guide d’administration d’OpenLDAP conseille de fixer le nombre de thread à 16 afin d’atteindre un bon équilibre de performance entre les opérations d’écriture et celles de lecture.

La configuration du processus "slapd" s’effectue à chaud et directement dans le DIT de configuration OLC (cn=config) au travers des attributs...

Au niveau du backend

1. Paramétrage du cache (ou la zone tampon)

Le cache est en fait une copie partielle ou totale des données de l’annuaire dans la mémoire vive (RAM) du système. Ce mécanisme permet donc de fournir des réponses plus rapides, car l’accès au disque (i/o) n’est dans certains cas pas nécessaire. En effet, les accès aux disques impliquent un temps de traitement plus long que l’accès à la mémoire. Ainsi, il est possible de réserver un espace de mémoire appelé "cache ou zone tampon" permettant d’y stocker directement les entrées de l’annuaire évitant ainsi d’accéder au disque et notamment pour les requêtes de type lecture. En revanche, pour les opérations de type "écriture", l’application ne se servira pas du cache excepté si les accès aux disques sont lents (high i/o rate). Ce cache ne contiendra évidemment pas la totalité des entrées, mais celles récemment utilisées susceptibles d’être consultées à nouveau.

La valeur optimale est évidemment le nombre d’entrées de l’annuaire (le nombre total de DN). Cependant, comme la mémoire est plutôt coûteuse et que toutes les entrées de l’annuaire ne sont pas forcément utilisées à la même fréquence, il convient de choisir un nombre d’entrées plus raisonnable.

Pour ce faire, des paramètres (surlignés sur la figure 17-1) permettant de configurer ces espaces de "cache" existent au niveau de la configuration des "backend" en vue d’augmenter significativement les performances de son annuaire.

Figure 17-1

Le paramètre olcDbCacheSize possède une valeur de 1000 entrées par défaut. Sa valeur optimale devrait être la totalité des entrées de l’annuaire + 10 %. Si la mémoire n’est pas suffisante, il faut au moins mettre une valeur pouvant contenir le nombre des entrées les plus utilisées.

Pour connaître le nombre d’entrée de l’annuaire, il faut exécuter la commande ci-dessous :


ldapsearch -b dc=example,dc=com dn 2>/dev/null | grep ˆdn | wc -l

Le paramètre olcDbIDLcacheSize...

Changer de backend

Afin d’optimiser les performances du serveur OpenLDAP, il peut être utile de changer de backend afin d’en utiliser un plus récent. En effet, OpenLDAP propose les trois types de backend suivants par ordre d’apparition : bdb, hdb et mdb. Bien que OpenLDAP préconise l’utilisation du backend "mdb", les distributions de type Red Hat intègrent seulement les backend de type "bdb" et "hdb". L’utilisation de ce dernier est par ailleurs conseillée pour les améliorations apportées par rapport à bdb, notammment la correction de bugs et la possiblité de renommer des sous-entrées de l’annuaire (voir figure 17-1).

Voici par exemple le résultat d’une tentative de renommage avec un backend "bdb" :


modifying rdn of entry "ou=users,dc=example,dc=com" 
   new RDN: "ou=users-RENAMED" (do not keep existing values) 
ldap_rename: Operation not allowed on non-leaf (66) 
   additional info: subtree rename not supported

Figure 17-1 : Message d’erreur sur backend "bdb"

La procédure (la plus simple) à appliquer sera donc la suivante :

Export des données au format LDIF (commande slapcat) :


[root@ldap01 tmp]# slapcat -b "dc=exemple,dc=com" -l 
/tmp/ldap-bkp.ldif 
5980e272 bdb_db_open: warning - no DB_CONFIG file found in  
directory /var/lib/ldap:...