Publié le : 05/11/2015 dans IT, Logiciel CRM Par : Jean-Sébastien Alet Tags :

Performance: plus vite, plus haut, plus fort…

Nous savons tous  que, pour que la mise en œuvre d’une solution telle qu’E-DEAL CRM soit couronnée de succès, il est crucial que l’application réponde rapidement aux actions des utilisateurs (après un clic, par exemple). Avec bien entendu les fonctionnalités, c’est un des facteurs principaux d’adoption (ou de rejet) de la solution par les utilisateurs.

Nous allons donc faire nôtre la devise chère à Pierre de Coubertin pour inaugurer cette série d’articles, qui vont aborder, de manière concrète et technique, la thématique des performances et des temps de réponse.

La base de données

Des facteurs qui influent sur la performance d’une application telle qu’E-DEAL CRM, le temps de réponse de la base de données est probablement le plus important. Dans ce premier billet, nous allons aborder un des aspects qui permettent d’améliorer ces temps de réponses, puis dans un second temps la meilleure manière de l’utiliser dans E-DEAL CRM.

Le but : accélérer les recherches

En résumant de manière très synthétique (c’est en fait un peu plus complexe), une base de données va disposer de trois voies possibles afin de trouver les enregistrements recherchés. Nous les listons ici par ordre décroissant de performance:

  • accès direct par clef primaire : c’est la voie la plus rapide mais elle ne peut être utilisée que dans certains cas  : par exemple lorsqu’on ouvre une fiche dans E-DEAL CRM.
  • accès indirect via index : idéalement utilisée lors de recherche,  c’est cette voie que nous allons chercher à mettre en œuvre dans toutes les listes de recherche de tables volumineuses.
  • parcours complet de la table : Cette dernière voie est à éviter à tout prix sur des tables volumineuses.

Créer des index : le réflexe prioritaire pour améliorer les temps de recherche

Attention, il reste nécessaire de suivre certaines règles basiques afin que cet index (qui a un coût lors des phases de création et de modification d’enregistrements) soit le plus profitable possible.

Index multi-colonnes

Un index multi-colonnes est un index qui porte sur plusieurs champs, et qui doit être privilégié lorsqu’une requête portera toujours sur les mêmes champs. Par exemple la requête suivante:

Select PerFst, PerName from Person where  PerCounselor='xxx' and PerFctID='yyy'

sera accélérée par un index portant sur  PerCounselor et PerFctID:

Create index Idx_PerSearch on Person(PerCounselor,PerFctID)

L’ordre des champs est  important si l’on souhaite utiliser ce même index pour des requêtes portant sur un seul champ : une recherche sur PerCounselor bénéficiera de cet index, contrairement à une autre portant uniquement sur PerFctID.

Un index multi-colonnes sera plus performant que deux index distincts sur chacun des champs.

Index avec fonction

Dans une optique de confort d’utilisation, la recherche doit souvent être insensible à la casse. Cela s’effectue dans E-DEAL CRM par l’utilisation d’une fonction de type Upper.

Select PerID from Person where upper(Pername) like 'XXX%'

Là aussi l’indexation devra prendre en compte ce fait, en utilisant cette fonction lors de sa création:

Create index Idx_PerSearchName on Person(Upper(PerName))

Si l’index n’est créé que sur le champ PerName uniquement, il ne sera pas utilisé par le SGBD lors d’une recherche sur upper(PerName) – à l’exception de SQL Server, qui est insensible à la casse par design.

Il est bien sur possible (et conseillé si nécessaire) de combiner index multi-colonnes et avec fonction:

Create index Idx_PerSearchName on Person(Upper(PerName),Upper(PerFstName))

Index or not Index

La création d’un index n’entraine pas automatiquement une amélioration des temps de réponse lors d’une recherche. Par exemple les recherches de type « contient » sur un champ texte (like ‘%XXX%’) n’utiliseront jamais d’index : elle seront donc à proscrire sur les tables volumineuses.

L’index est également hors jeu si le champ est très peu discriminant, c’est-à-dire qu’il ne contient que peu de valeurs distinctes : indexer un champ booléen sera plus contre-productif qu’utile. De plus les opérations de tri et de groupement (clauses order by et group by) peuvent bénéficier des index.

Enfin les bases de données permettent de connaitre le plan d’exécution d’une requête, et donc quels index sont (ou ne sont pas) utilisés

 Ressources utiles

Faut-il le préciser, la documentation de votre SGBD sera bien sûr la première source de renseignements précieux, mais il faut noter le site Use the index, Luke  ressource de premier ordre à  mettre en favori.

Par ailleurs, si Oracle ou SQL Server bénéficient « nativement » d’outils permettant de repérer les requêtes avec de mauvais temps de réponses, Postgres gagne à être complété avec des outils externes, tels que PGBadger, qui permet d’analyser efficacement ses fichiers de log.

A suivre…

Prochain post: comment bénéficier des index dans E-DEAL CRM…

Enregistrer

Partager cet article
Lire également
Leave a comment