2 Conception de l'environnement de production
2.3 Optimisation des performances
L'optimisation des performances est un sujet complexe. L'application utilisateur Identity Manager repose sur diverses technologies avec un grand nombre d'interactions. Il n'est pas possible
d'anticiper chaque scénario de configuration ou d'interaction utilisateur qui pourrait de traduire par des performances médiocres. Néanmoins, certains sous-systèmes sont sujets aux meilleures pratiques qui améliorent les performances. Ils sont répertoriés ci-dessous.
2.3.1 Consignation
L'application utilisateur permet la consignation via Novell Audit et via l'infrastructure Open Source Apache log4j. La consignation via Novell Audit est désactivée par défaut. En revanche, les
consignations de fichier et de console via log4j sont activées par défaut.
Remarque :Les types d'événements que vous pouvez consigner, ainsi que le mode d'activation et de désactivation de la consignation, sont abordés au Chapitre 5, « Configuration de la
consignation », page 119 et au Chapitre 12, « Configuration de la consignation », page 211 plus loin dans ce guide.
Les paramètres de configuration de log4j sont contenus dans le fichier log4j.xml qui se trouve sous
$IDMINSTALL/jboss/server/IDMProv/conf/. Près du bas de ce fichier, vous trouverez l'entrée suivante :
<root>
<priority value="INFO" />
<appender-ref ref="CONSOLE" />
<appender-ref ref="FILE" />
</root>
L'assignation d'une valeur à root assure que les appenders du journal qui n'ont pas de niveau assigné de façon explicite héritent du niveau root (dans ce cas, INFO). Par exemple, par défaut, l'appender FILE n'a pas de niveau de seuil assigné et assume celui de root.
Les niveaux de consignation possibles utilisés par log4j sont DEBUG, INFO, WARN, ERROR et FATAL, tels que le définit la classe org.apache.log4j.Level. Le mauvais usage de ces paramètres peut se révéler coûteux en termes de performances.
En règle générale, on n'utilise INFO ou DEBUG que pour déboguer un problème particulier.
(FRA) 27 February 2006 Tout appender inclus dans le root et dont le niveau de seuil est défini, doit définir ce seuil sur
ERROR, WARN ou FATAL sauf (comme on vient de l'expliquer) si vous déboguez quelque chose.
Le niveau de performances avec des niveaux élevés de consignation a moins en commun avec le caractère détaillé des messages qu'avec le simple fait que les consignations de fichier et de console, dans log4j, impliquent des écritures synchrones. Une classe AsyncAppender est disponible, mais elle ne garantit pas de meilleures performances. Les problèmes (qui sont bien connus et qui sont des problèmes log4j Apache, et non des problèmes Identity Manager) sont exposés à l'adresse http://
logging.apache.org/log4j/docs/api-1.2.8/org/apache/log4j/performance/Logging.html.
Le paramètre INFO par défaut du fichier de configuration du journal de l'application utilisateur (ci-dessus) est satisfaisant pour de nombreux environnements. Par contre, lorsque les performances sont essentielles, vous devez envisager de remplacer l'entrée log4j.xml ci-dessus par :
<root>
<priority value="ERROR"/>
<appender-ref ref="FILE"/>
</root>
En d'autres termes, supprimez CONSOLE et définissez le niveau de consignation sur ERROR. Pour une configuration de production entièrement testée/déboguée, il est inutile d'effectuer la
consignation au niveau INFO, ni de laisser la consignation CONSOLE activée. Les bénéfices de performances liés à cette désactivation peuvent être significatifs.
Pour plus d'informations sur log4j, reportez-vous à la documentation disponible à l'adresse http://
logging.apache.org/log4j/docs.
Pour plus d'informations sur l'utilisation de Novell Audit avec Identity Manager, reportez-vous au Guide d'administration de Novell Identity Manager.
2.3.2 Coffre-fort d'identité
Les requêtes LDAP risquent de créer un goulot d'étranglement dans un environnement de serveur d'annuaire très utilisé. Pour conserver un niveau élevé de performances avec un grand nombre d'objets, Novell eDirectory (qui constitue la base du coffre-fort d'identité dans Identity Manager) enregistre les informations fréquemment demandées et les stocke dans des index. Lorsqu'une requête complexe est exécutée sur des objets dont les attributs sont indexés, elle est renvoyée beaucoup plus rapidement.
eDirectory est fourni avec les attributs suivants déjà indexés :
Aliased Object Name
(FRA) 27 February 2006
Lorsque vous installez Identity Manager, le schéma d'annuaire par défaut est étendu avec les types objectclass et les nouveaux attributs relatifs à l'application utilisateur. Les attributs spécifiques de l'application utilisateur ne sont pas indexés par défaut. Pour améliorer les performances, vous pourrez trouver pratique d'indexer certains de ces attributs (et éventuellement quelques attributs LDAP classiques également), en particulier si votre conteneur utilisateur doit contenir plus de 5 000 objets.
L'idée générale est de n'indexer que les attributs dont vous savez qu'ils doivent faire l'objet de requêtes régulières. Ces attributs peuvent être très différents selon les environnements de
production. La seule manière de connaître avec certitude quels sont les attributs très utilisés consiste à recueillir des statistiques de prédicat lors de l'exécution. Toutefois, le processus de recueil lui-même diminue les performances.
Le processus de recueil des statistiques de prédicat est abordé en détails dans le Guide
d'administration de eDirectory. L'indexation y est également abordée en détails. En général, vous devez procéder de la façon suivante :
• Utilisez Console One pour activer le recueil des statistiques de prédicat pour les attributs qui vous intéressent
• Placez le système en charge
• Désactivez le recueil des statistiques et analysez les résultats
• Créez un index pour chaque type d'attribut qui pourrait en bénéficier
Si vous savez déjà quels attributs vous voulez indexer, il est inutile d'utiliser Console One. Vous pouvez créer et gérer les index dans iManager via Maintenance de eDirectory > Index. Par exemple, si vous savez quels utilisateurs de votre organigramme sont susceptibles d'effectuer des recherches basées sur l'attribut isManager, vous pouvez tenter d'indexer cet attribut pour savoir si les
performances s'en trouvent améliorées.
Remarque :Il est recommandé d'indexer, au minimum, les attributs manager et isManager.
Pour une présentation détaillée de l'indexation des attributs et des performances, reportez-vous au chapitre consacré à l'optimisation d'eDirectory dans l'ouvrage Novell’s Guide to Troubleshooting eDirectory (Guide de dépannage de Novell eDirectory) de Peter Kuo et Jim Henderson (QUE Books, ISBN 0-7897-3146-0).
Reportez-vous également au chapitre consacré à la maintenance de Novell eDirectory (qui fournit un guide de réglage des performances) dans le Guide d'administration de eDirectory principal.
2.3.3 JVM
La quantité de tas allouée à la machine virtuelle Java peut avoir des conséquences négatives sur les performances. Si vous spécifiez des valeurs min ou max de mémoire qui sont trop faibles ou trop élevées (trop élevées signifiant plus que la mémoire physique de la machine), il se peut que cela se traduise par l'échange excessif de fichiers d'échange.
(FRA) 27 February 2006 Vous pouvez définir la taille JVM max pour le serveur JBoss en modifiant le fichier run.conf ou
run.bat (le premier pour Linux, le second pour Windows) sous [IDM]/jboss/bin/ dans un éditeur de texte. Augmentez “-Xmx” de 128m à 512m ou plus haut éventuellement. Vous devrez peut-être effectuer des tests pour déterminer le paramètre optimal correspondant à votre
environnement particulier.
Remarque :Vous trouverez des conseils relatifs au réglages des performances de JBoss et de Tomcat à l'adresse http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming (http://
wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming)
2.3.4 Valeur de timeout de session
Le timeout de session (temps pendant lequel un utilisateur peut laisser une page sans intervention dans son navigateur avant que le serveur ne déclenche l'apparition d'une boîte de dialogue d'avertissement de timeout de session) peut être modifié dans le fichier web.xml de l'archive IDM.war. Cette valeur doit être réglée pour correspondre au serveur et à l'environnement
d'utilisation dans lequel l'application sera exécutée. Il est généralement recommandé de définir un timeout de session aussi faible que possible. Si les exigences de l'activité peuvent tolérer un timeout de 5 minutes, cela permet au serveur de libérer les ressources inutilisées deux fois plus tôt que si cette valeur était de 10 minutes. Cela rend l'application Web plus performante et plus évolutive.
Prenez en considération les éléments suivants lorsque vous réglez le timeout de session :
• Des timeouts de session plus longs peuvent provoquer une insuffisance de mémoire du serveur JBoss si de nombreux utilisateurs doivent se loguer pendant une courte période. Cela est vrai de n'importe quel serveur d'applications qui a trop de sessions ouvertes.
• Lorsqu'un utilisateur se connecte à l'application utilisateur, une connexion LDAP est créée pour l'utilisateur et est liée à la session. Ainsi, plus il y a de sessions ouvertes, plus le nombre de connexions LDAP ouvertes est élevé. Plus le timeout de session est long, plus ces connexions restent ouvertes longtemps. Un nombre trop élevé de connexions au serveur LDAP (même si elles sont inactives) risque de causer la dégradation des performances du système.
• Si le serveur rencontre des erreurs OutOfMemoryErrors, et si les paramètres de réglage de segment JVM et de nettoyage de la mémoire ont déjà été réglés de façon optimale pour les environnements du serveur et d'utilisation, on peut envisager de réduire le timeout de session.
Pour régler la valeur de timeout de session, vous devez ouvrir l'archive IDM.war, rechercher le fichier web.xml qu'elle contient et modifier la partie suivante de ce fichier (en particulier, la valeur numérique par défaut, ici égale à 20, ce qui signifie 20 minutes) :
<session-config>
<session-timeout>20</session-timeout>
</session-config>
Vous devez ensuite enregistrer le fichier et l'archive, puis redémarrer le serveur.
Remarque :L'édition manuelle des fichiers d'archive Web doit être effectuée de préférence par une personne expérimentée dans le développement et le déploiement d'applications Web Java.
(FRA) 27 February 2006