El tamaño de la caché es posiblemente el factor que más afecta al rendimiento general de eDirectory. Cuanto mayor sea el número de elementos (bloques y entradas) que pueden almacenarse en caché, mejor será el rendimiento general. El porcentaje de veces que se encuentran los bloques o las entradas en la caché se conoce como la proporción de impacto. Una proporción de impacto elevada da como resultado un mejor rendimiento. iMonitor puede utilizarse para ver la proporción de impacto.
La caché de bloques aleatorios es más útil para las operaciones de actualización. La caché de entrada es muy útil para las operaciones que realizan una búsqueda de base para una entrada. Sin embargo, las búsquedas de un nivel y de subárbol utilizan tanto la caché de bloques lógicos como la caché de bloques aleatorios. La caché de bloques aleatorios se utiliza para recuperar los índices. Cree el tipo correcto de índices que sea necesario. Para obtener más información, consulte la sección Selección de índices.
Un fallo en la caché de bloques aleatorios puede provocar una operación de lectura de disco. Las lecturas de disco siempre resultan caras, pero pueden evitarse si se recupera un bloque de la caché del sistema de archivos.
La cantidad de memoria necesaria para almacenar la base de datos completa en la caché de bloques aleatorios se corresponde casi con el tamaño de la base de datos del disco, y la cantidad de memoria necesaria para almacenar la base de datos completa en la caché de bloques lógicos es entre dos y cuatro veces el tamaño base de datos del disco. Si tiene menos memoria en un sistema, pruebe con una caché de bloques lógicos más pequeña y una caché del sistema de archivos o de bloques aleatorios mucho mayor.
Si las lecturas se reducen a un conjunto de entradas del directorio, aumente la caché de bloques lógicos siempre que el resultado sea una mayor proporción de impacto de la caché de bloques lógicos.
Si el patrón de lectura es completamente aleatorio y el archivo DIB es mucho mayor que la memoria RAM disponible, debe tener una caché de bloques aleatorios o del sistema de archivos más grande que la caché de bloques lógicos.
Cualquier método que utilice para optimizar eDirectory con el fin de mejorar el rendimiento requiere pruebas empíricas. Una buena proporción entre la caché de bloques lógicos y la caché de bloques aleatorios para entornos con muchas búsquedas sería de 2:1. Asegúrese de que queda suficiente memoria para otros procesos. Evite el intercambio de páginas, aunque esto implique reducir los tamaños de la caché FLAIM.
FLAIM proporciona almacenamiento en caché preasignado, por lo que la memoria asignada a la caché de eDirectory nunca es fragmentada por el administrador de memoria del sistema operativo nativo.
Los índices están diseñados para mejorar el rendimiento de las búsquedas de un nivel o de subárbol. Los grupos dinámicos también utilizan búsquedas de un nivel o de subárbol. Los índices no se utilizan para búsquedas de base.
Los índices de presencia no diferencian entre valores presentes y no presentes (eliminados), por lo que se utilizan principalmente para fines internos. Si las aplicaciones ejecutan una consulta de búsqueda de tipo de presencia, este índice no se utiliza nunca, de modo que no se deberían crear índices de presencia para las aplicaciones.
Las aplicaciones pueden crear un índice de valor para un atributo, que es suficiente para la mayoría de las búsquedas. FLAIM puede utilizar un índice de valor para llevar a cabo tanto búsquedas de presencia como búsquedas de subcadena en los atributos.
Un índice de subcadena puede ralentizar considerablemente las actualizaciones realizadas en un atributo. El número de bloques de índice necesario para admitir un índice de subcadena es bastante grande en comparación con el índice de valor. Esto significa que se requiere más caché de bloques aleatorios para almacenarlos en caché. Cree un índice de subcadena solo cuando sea necesario. Un índice de valor debería ser suficiente para la mayoría de las búsquedas. Sin embargo, si las búsquedas de subcadenas no producen un rendimiento aceptable con un índice de valor, puede crear un índice de subcadena en dichos atributos.
Si una operación de búsqueda tarda mucho tiempo en completarse a pesar del índice seleccionado, puede introducir un índice de valor más reciente en uno de los atributos del filtro de búsqueda. Seleccione el atributo que produzca los mejores resultados al indexarlo.
La caché de bloques aleatorios es más útil para las operaciones de actualización. Los índices también se almacenan en la caché de bloques aleatorios. Aunque los índices agilizan las búsquedas, el hecho de tener demasiados índices ocupa al servidor con su mantenimiento. Los índices se modifican al modificar, añadir o eliminar valores de atributo. Durante las operaciones de carga de grandes volúmenes, los índices se pueden inhabilitar para que la carga sea más rápida.
Tener el directorio RFL en un disco diferente al directorio DIB mejora el rendimiento.
Un límite aceptable para el tiempo de respuesta para una operación de actualización puede controlarse mediante el uso de maxdirtycache. Por ejemplo, si 5 segundos es un límite aceptable para la respuesta del servidor y la velocidad de escritura de disco aleatoria es de 20 MB por segundo, maxdirtycache debe establecerse en 20x5 = 100 MB. Asegúrese de que la caché de bloques aleatorios puede mantener estos bloques modificados en la memoria. Consulte la Sección 5.2.2, Modificación de los ajustes de la caché FLAIM a través de _ndsdb.ini para obtener más información.