Le titre de ce billet correspond à une question reçue régulièrement par notre support, seul le nombre "<?>" d'enregistrements et le temps annoncé changent. Ces demandes peuvent être relatives à une application Windows, un service Windows, un webservice, un site Web (...) qui utilise des données en client/serveur (HFSQL Client/Serveur, Oracle, MySQL, SQL Server...).

Dans pareil cas, il n'est pas possible de déterminer le temps "normal" que doit prendre une interrogation et son traitement. En effet, le temps nécessaire pour la récupération d'une requête type SELECT est dépendant de très nombreux facteurs :

• volume total des données manipulées (nombre total et taille des enregistrements),
• performances disque permettant l'accès aux données,
• performances de la mémoire du serveur qui héberge les données (Windows serveur par exemple doit être configuré spécifiquement pour ne pas monopoliser la mémoire pour ses propres caches),
• mode de compilation du système serveur et du moteur de base de données (gestion des caches limitée en 32 bits),
• nombre d'enregistrements qui doivent figurer dans le résultat de la sélection,
• taille de chaque ligne du résultat de l'interrogation,
• état du trafic réseau lors de la récupération du résultat,
• définition des index de la base de données dans les tables concernées par l'interrogation,
• délai depuis la dernière actualisation des statistiques des index,
• traitement fait sur le résultat de la requête une fois qu'il est récupéré dans l'application...

Pour résumer, en la matière, chaque cas est pratiquement unique ! Notre support peut procéder si besoin à des tests de performances, mais avant cela, voici les principales vérifications à effectuer en cas de doute sur les performances d'une requête.

Avant tout, il faut bien "mettre à plat" le besoin de départ, afin de vérifier qu'il est bien fondé. D'expérience, il n'est pas rare que les requêtes les plus longues, sont celles qui n'ont pas lieu d'être lancées directement depuis l'IHM d'une application, et qui pourraient à l'inverse s'exécuter via une procédure stockée du serveur de données. En effet, c'est un des intérêts majeur de l'utilisation d'une base client/serveur, l'exécution de procédures stockées peut permettre une consolidation de données de façon transparente pour les utilisateurs des applications, qui profitent ensuite d'un accès immédiat aux résultats qu'ils attendent.

Passé ce stade, il faut évaluer le volume de données à récupérer, afin de voir en fonction des caractéristiques du réseau reliant l'application au serveur de données si il n'y a pas un goulet d'étranglement à ce niveau. Pour caricaturer, le temps de récupération d'une même requête de sélection de 2 000 lignes sur 2 millions, ne sera pas identique si la connexion au serveur de données se fait via le réseau local, ou en 3G. Cela va sans dire, mais là aussi l'expérience montre qu'il n'est pas rare d'en demander tout simplement trop à un serveur de données pour un débit de connexion donné.

Le dimensionnement du serveur de données est ensuite fondamental. Il faut se reporter aux recommandations des éditeurs de base de données. Dans le cas de HFSQL Client/Serveur :

• recommandations de sécurité
• billet sur l'évaluation du dimensionnement

Typiquement lorsqu'un serveur manque de RAM, la gestion des caches n'est pas optimale pour garantir de bonnes performances, et si le serveur doit faire du "swap" disque, les performances s'écroulent.

La structure des tables est également importante, un index manquant peut nécessiter un parcours de tous les enregistrements d'une table, là ou quelques lectures auraient été suffisantes. Dans le cas de HFSQL il faut vérifier :

• les index proposés par le menu "Optimiser" de l'éditeur de requêtes ou la fonction HSuggèreClé,
• la mise à jour régulière des statistiques,
• le traitement de la requête avec une requête EXPLAIN,
• dans le cas de données HFSQL Classic, vérifier de plus la rapidité du disque et/ou du partage qui héberge les données, qu'il n'y a pas d'interaction avec d'autres processus (antivirus), qu'il n'y a pas une recherche de données en bibliothèque avant le disque (cf. fonction HChangeLocalisation), ou un fichier .REP trop volumineux contenant des emplacements de fichiers obsolètes.

Le traitement globale doit être contrôlé, à l'aide de l'analyseur de performances (profiler). Il est fréquent que le coût en temps d'un traitement ne soit pas là où on le suspecte au premier abord. Les rapports de performances permettent immédiatement de situer une attente, afin de rapidement orienter les optimisations.

Enfin si besoin notre support peut effectuer un test de performances, à partir d'une étude de cas. Il suffit de formuler une demande par le menu "Aide" du volet "Accueil" du ruban des versions 18, choix "Requête au support technique". La demande doit nécessairement contenir :

• détail du cas de figure,
• version de la base de données (à voir avec son administrateur, ou le centre de contrôle dans le cas de HyperfileSQL),
• version du client de la base de données (impact important en Oracle, SQL Server)
• caractéristiques serveurs / réseau
• les délais observés / attendus,
• un lien vers un serveur Web ou Ftp permettant de télécharger une archive zip contenant :
• • un projet de test,
  • une fenêtre commentée lançant le traitement (libellés explicatifs "cliquez ici, "observez que"...)
  • la(es) requête(s) .WDR,
  • l'analyse (dossier \NomAnalyse.wdx\ ou \NomAnalyse.ana\ sans ses sous-dossiers)
  • un jeu de données *.FIC permettant l'exécution dans le cas d'une base HFSQL, un script SQL (fichier texte avec Create table et Insert) dans le cas d'une autre base.