Le dimensionnement du cache est sans doute le facteur ayant la plus forte incidence sur les performances globales de eDirectory. Plus le nombre d'éléments (blocs et entrées) pouvant être mis en cache est important, meilleures sont les performances globales. Le pourcentage d'occurrences d'entrées ou de blocs trouvées dans le cache est appelé rapport d'occurrence. Un rapport élevé se traduit par de meilleures performances. iMonitor permet d'afficher le rapport d'occurrence.
Le cache de blocs s'avère particulièrement utile dans les opérations de mise à jour. Le cache d'entrées est particulièrement utile pour les recherches d'entrées basées sur une étendue définie. Toutefois, les recherches portant sur un niveau et sur une sous-arborescence utilisent le cache d'entrées et le cache de blocs. Le cache de blocs permet de récupérer les index. Créez le type d'index approprié ; pour plus d'informations, consultez la section Choix des index.
Une panne du cache de blocs peut entraîner une opération de lecture de disque. Les lectures de disque sont toujours coûteuses, mais elles peuvent être évitées si un bloc est récupéré à partir du cache du système de fichiers.
La quantité de mémoire nécessaire pour mettre dans le cache de blocs l'intégralité de la base de données équivaut presque à la taille de la base de données sur le disque. Quant à la quantité de mémoire requise dans le cache d'entrées pour cette même base de données, elle équivaut à deux à quatre fois la taille de la base de données sur le disque. Lorsque la mémoire système est inférieure, essayez d'utiliser un cache d'entrées plus petit et un cache de blocs ou de système de fichiers beaucoup plus grand.
Si les lectures sont localisées sur un ensemble d'entrées de l'annuaire, vous devez augmenter le cache d'entrées jusqu'à améliorer le rapport d'occurrence.
Si le modèle de lecture est totalement aléatoire et que le fichier DIB est beaucoup plus volumineux que la mémoire RAM disponible, le cache de blocs ou de système de fichiers doit être plus grand que le cache d'entrées.
Toute méthode utilisée pour ajuster eDirectory dans le but d'améliorer les performances doit faire l'objet de tests empiriques. Pour les environnements à forte activité de recherche, un rapport d'occurrence de 2:1 dans le cache de blocs est un rapport correct. Vérifiez que la mémoire disponible est suffisante pour d'autres processus. Évitez l'échange de pages, même si cela implique la réduction de la taille des caches FLAIM.
Étant donné que le gestionnaire FLAIM préalloue la mise en cache, la mémoire allouée au cache eDirectory n'est jamais fragmentée par le gestionnaire de mémoire natif du système d'exploitation.
Les index sont conçus pour améliorer les performances des recherches sur un niveau ou dans une sous-arborescence. Les groupes dynamiques utilisent également des recherches sur un niveau ou dans une sous-arborescence. Les index ne sont pas utilisés pour les recherches basées sur une étendue définie.
Étant donné qu'un index Presence ne fait pas de différence entre les valeurs présentes et non présentes (supprimées), il est utilisé principalement en interne. Si les applications effectuent une recherche de type Presence, cet index n'est jamais utilisé, si bien qu'aucun index Presence ne doit être créé pour les applications.
Les applications peuvent créer un index Value pour un attribut, ce qui est suffisant pour la plupart des recherches. Le gestionnaire FLAIM peut utiliser un index Value pour effectuer des recherches de type Presence et Substring dans les attributs.
Un index Substring peut ralentir considérablement les mises à jour effectuées sur un attribut. Le nombre de blocs d'index requis pour prendre en charge un index Substring est assez important par rapport à l'index Value. Cela signifie que leur mise en cache nécessite un cache de blocs plus important. Créez un index Substring uniquement lorsque cela est nécessaire. Un index Value devrait suffire pour la plupart des recherches. Toutefois, si des recherches Substring ne donnent pas de performances acceptables avec un index Value, vous pouvez créer un index Substring sur ces attributs.
Si l'exécution d'une recherche est longue malgré l'index choisi, vous pouvez intégrer un index Value plus récent sur l'un des attributs de filtre de la recherche. Choisissez l'attribut qui produit les meilleurs résultats lors de l'indexation.
Le cache de blocs s'avère particulièrement utile dans les opérations de mise à jour. Les index se trouvent également dans le cache de blocs. Les index accélèrent les recherches, mais s'ils sont trop nombreux, le serveur consacre ses ressources à leur gestion. Les index sont modifiés si les valeurs d'attribut sont modifiées, ajoutées ou supprimées. Pendant les opérations importantes de téléchargement, les index peuvent être désactivés pour que le téléchargement soit plus rapide.
Le fait d'avoir l'annuaire RFL sur un disque et l'annuaire DIB sur un autre améliore les performances.
La limite acceptable en matière de temps de réponse pour une opération de mise à jour peut être contrôlée à l'aide de la commande maxdirtycache. Par exemple, si la limite acceptable de temps de réponse du serveur est de 5 secondes et que la vitesse d'écriture aléatoire sur le disque est de 20 Mo par seconde, la commande maxdirtycache doit être définie comme suit : 20 x 5 = 100 Mo. Assurez-vous que le cache de blocs peut contenir ces blocs altérés dans la mémoire. Pour plus d'informations, reportez-vous au Section 5.2.2, Modification des paramètres de cache FLAIM dans _ndsdb.ini.