Documentation SDX-2 Télécharger Installer Présentation Configuration Indexation Recherche OAI Javadoc Référence API-XSP Migration Schemas Performances Concepts A améliorer Mesures | # Les aspects à améliorer en terme de performance Les développeurs de SDX connaissent déjà un certain nombre de fonctions dans SDX où les performances devraient être améliorées. Nous évitons ici de parler d'outils ou fonctions générales telles que Java, processeurs XSLT, etc. ## Tri Le tri des résultats de recherche (en fait, le tri autre que le tri naturel, soit le tri par ordre de pertinence au sens où l'entendent les développeurs de Lucene) est une opération lente en SDX lorsque le nombre de résultats est grand. De plus, la quantité de mémoire vive nécessaire peut être grande. Différentes solutions pourraient être mises en oeuvre afin d'améliorer l'un ou l'autre de ces aspects. Ne pas effectuer le tri uniquement en mémoire, mais plutôt utiliser les disques, afin de réduire les besoins en mémoire sur de grands ensembles. Utiliser d'autres algorithmes de tri que ceux proposés par Java. Permettre au développeur d'indiquer un seuil à partir duquel les résultats ne devraient pas être triés. Aucun développement dans ce sens n'est prévu pour l'instant. ## Listes de termes SDX permet de consulter facilement les listes de termes que l'on retrouve dans les champs. Cette fonction est essentielle dans une application documentaire, mais dans l'outil de recherche Lucene il ne s'agit pas d'une fonction particulièrement optimisée. Elle est donc relativement lente, et ce à partir du moment où il y a un grand nombre de termes dans l'ensemble des champs d'une base. Pour y remédier, on pourrait créer ces listes hors Lucene, et gérer indépendamment les différents champs, ce qui évite un problème avec l'implantation actuelle où le nombre de termes global est un facteur limitant, même si on cherche les termes d'un champ où il y en a peu. De plus, dans ces listes hors Lucene, il serait possible de stocker les termes dans l'ordre de tri souhaité dans la configuration du champ (en fonction de la langue). Ce développement devrait être réalisé par AJLSM au cours du premier trimestre 2003. ## Recherche par intervalle de dates La recherche par intervalle de dates n'est pas la plus optimisée dans SDX (en fait, dans Lucene). Elle passe par la construction d'un objet mémoire qui contient un bit par document dans la base. Ainsi, pour une base d'1 million de documents, cet objet fait au minimum 125Ko, ce qui n'est pas énorme, mais qui demande un certain temps. Pour remédier à cette situation, il serait intéressant de cacher cet objet et de le réutiliser dans des recherches subséquentes. Cette tâche n'est pas encore prévue. ## Cache Cocoon 2, sous-jacent à SDX, possède un système de cache extrêmement sophistiqué. Il serait intéressant de l'étudier à fond et de proposer des recommandations précises pour son utilisation dans des applications SDX. Cette tâche n'est pas prévue pour l'instant.
| Auteur : Martin Sévigny ( AJLSM ) - 2003/01/29

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.