performances

Utilisation de SLAMD pour les benchmarks LDAP

13/10 2021

Lorsqu'on réalise des études comparatives sur les annuaires LDAP, il est fréquent que le client demande d'établir des tests de performances, pour s'assurer que la solution en place sera capable de répondre à ses exigences.

Pour faire cela, j'utilisais souvent les outils authrate ou searchrate présents dans les binaires des annuaires de Forgerock ou Ping.

Si ces outils permettent de tester de manière unitaire, et avec un certain nombre de paramètres, ils manquait certaines possibilités / fonctionnalités :

Optimisation du temps de démarrage Ubuntu Linux

07/10 2018

Depuis quelques temps, je trouve que le temps de démarrage de mon PC sous Ubuntu est bien long... alors que le disque principal est un SSD.

Identifier le temps total de démarrage

Sur les O.S. qui utilisent systemd, il existe une commande permettant de connaître le temps nécessaire au démarrage : systemd-analyze.

Sans option, cette commande donne juste le temps total nécessaire au démarrage, ainsi que le temps après lequel on arrive à l'écran de connexion. Exemple :

OpenDJ : mise en place du suivi des connexions

19/12 2017

Par défaut, il n'est pas possible de déterminer la date de dernière connexion réussie sur un annuaire LDAP (last login time). Seules les erreurs de connexion peuvent être détectées dans les politiques de mots de passe.

Parfois cependant, il est intéressant de connaître la date de dernière connexion, afin de pouvoir supprimer - ou bloquer - des comptes inutilisés depuis plusieurs mois.

OpenIDM : purge des tables audit

14/12 2016

Contexte

Dans un environnement client OpenIDM 3.1 en production depuis plusieurs mois, l'accès à l'écran d'administration des mappings met de plus en plus longtemps à s'afficher.

English Summary

It may help : if the access time to mapping administration form in OpenIDM becomes very slow, then check the numbers of lines in auditrecon table, and delete old records.

OpenIDM : réduire les logs du scheduler

22/11 2016

Chez un client, nous avons activé le niveau de log à INFO par défaut afin d'avoir des traces des opérations, notamment car on travaille sur la base d'un changelog depuis un annuaire LDAP Sun, avec un polling toutes les 10 secondes. Plusieurs providers sont ainsi déclenchés : l'un pour les utilisateurs du LDAP, un autre pour les groupes, et encore un pour les groupes AD.

Ceci a pour effet de bord de remplir les logs d'informations peu utiles, du genre :

Tuning OpenLDAP avec DB_CONFIG

13/10 2016

Afin d'améliorer les performances de OpenLDAP, il est recommandé de pouvoir utiliser le plus de cache possible pour monter en mémoire les données OpenLDAP.

Ceci se fait via les réglagles du fichier DB_CONFIG, qui se trouve dans le répertoire contenant les données de l'annuaire, et qui permet de paramétrer la base de données Berkeley, utilisée comme back-end de stockage par OpenLDAP.
Par défaut, il n'y a pas de fichier DB_CONFIG créé. Par contre on peut trouver un exemple dans /usr/share/openldap-servers/DB_CONFIG.example :

Influence du paramétrage APC sur les performances Drupal

04/08 2014

Avec une version PHP inférieure à 5.5 il est recommandé d'utiliser un cache d'OpCode. Ce cache permet d'améliorer les performances de PHP, en mettant en cache le code PHP une fois qu'il a été analysé.

L'un des caches les plus utilisés est APC. Son installation sur une distribution type Debian consiste simplement en une commande

apt-get install php-apc

Par défaut, la taille mémoire réservée est de 32 Mo.

Performances Drupal

12/02 2013

Drupal est généralement basé sur une plate-forme LAMP (Linux / Apache / MySQL / PHP), même si on peut au final changer la majorité des couches, sauf le PHP.

Plusieurs options sont donc possibles pour améliorer les performances, qui peuvent parfois être calamiteuses sur un serveur mal dimensionné :

S'abonner à performances