Tests de performance

MicFrancisco edited this page May 13, 2013 · 3 revisions

histo perform

Le graphique ci-dessus représente bien les performances entre la version 1 et la version 2.

La différence est flagrante sur la recherche de concordance, pour nos tests sur la concordance nous nous sommes appuyés sur un corpus de 85 œuvres sur la version 1 et 2. Cependant, les tests effectués sur la version 2 ne prennent pas en compte l’interface graphique, car celle-ci est encore en phase de développement.

Tests de performance :

Le test de performance a été effectué dans des conditions les plus proches possibles pour les 2 versions du programme (base de 85 œuvres…). Les principales différences se trouvent dans le fait que le test de la version 1 a été exécuté via un serveur distant tandis que la version 2 était hébergée en local. De plus, l’interface graphique de la version 2 n’étant pas finalisée, cette dernière n’est pas prise en compte dans les tests de performance. Néanmoins, les résultats finaux ne dépendent que peu de ces paramètres et les résultats obtenus peuvent donc permettre une analyse critique des 2 versions. Ainsi, il est évidant aux vues des graphiques que la version 1 du programme avait de grandes difficultés lors des recherches de concordances. Cela se traduit par un temps d’accès moyen à l’information de plus de 16 secondes. Dans la version 2, ce problème semble résolu avec un temps de recherche moyen de 1 seconde seulement. On remarque donc que le temps nécessaire à une recherche de concordance est significativement plus court sur la version 2 que sur la version 1. Ceci s’explique en grande partie par l’utilisation de requête NoSQL et non plus SQL.

Fonctionnement SQL :

Les requêtes sont basées sur une vue. La vue regroupe sur une même table les différentes œuvres et les phrases qu’elles contiennent avec différents éléments pour les identifiées dans les différentes langues. Le problème principal de cette approche est que la vue est recalculée à chaque fois qu’elle est appelée (même si la requête ne retourne rien) et cela ralentit énormément le processus de recherche. Il est en effet impossible de garder la vue dans un cache. De plus, en conservant toutes les contraintes de la version 1 (SQL…) il est difficilement possible d’optimiser la recherche. Le problème rencontré paraît donc insoluble.

Fonctionnement NoSQL :

Dans la version 2 la recherche se base uniquement sur un index qui est créé et mis à jour régulièrement. Cet index contient tous les « bouts de phrases » de toutes les œuvres (originales ou traduction) et ces « bouts de phrases » sont ainsi classés par ordre alphabétique. On entend par « bout de phrase » tout sous-ensemble de phrase commençant par un mot jusqu'au dernier mot de la phrase qui le contient. Par exemple la phrase « Un petit chien » sera présente dans l’index en 3 entrées distinctes « Un petit chien », « petit chien » et « chien ». Ainsi lors d’une recherche de concordance il suffit de se déplacer dans l’index jusqu'au mot/expression recherchée. Ce « bout de phrases » est stocké dans l’index avec l’identifiant de l’œuvre d’où il provient. Il est donc par la suite très facile d’aller rechercher le début de la phrase ainsi que les traductions relatives au bloc correspondant à la recherche.