Conseils pour améliorer les performances d'InterBase

Définissez des index sur tous les champs utilisés dans des tris ou jointures. Les index sont des structures de données de type « arbre balancé » ou B-Tree qui offrent une nette amélioration en termes de rapidité lors de recherches de valeurs. Cela est particulièrement utile quand vous triez en fonction d'un champ ou joignez deux tables sur un champ commun.

Rappelez-vous qu'un index Interbase spécifie le sens du tri (ASCENDING et l'inverse DESCENDING), et le sens d'un index doit correspondre au sens du tri spécifié dans la requête. Si vous prévoyez d'utiliser les deux sens de tri, créez deux index sur les clefs de tri.

Les insertions et modifications de données nécessitent une mise à jour des index, ce qui peut provoquer une perte de performances lors de ces opérations, mais résulter en gain appréciable lors des requêtes ultérieures.

Afin de réduire les pertes de performances lors d'un INSERT, prévoyez de désactiver les index pour les INSERT de données en quantité. Ils ne pourront plus alors accélérer les requêtes, mais ne seront pas mis à jour par les INSERTions de données. Lorsque l'insertion des données est terminée, réactivez les index. Ils seront mis à jour et rebalancés en une passe pour toutes les données insérées.

Reconstruisez régulièrement les index en les désactivant puis les réactivant (ALTER INDEX nomindex INACTIVE suivi de ALTER INDEX nomindex ACTIVE). Recalculez l'index de sélectivité (SET STATISTICS INDEX nomindex) si un changement dans la table affecte la distribution moyenne des valeurs dans les données. Les index sont reconstruits de manière identique lors d'un restore.

Interbase analysera une requête et l'optimiseur proposera les index qui devront être utilisés pour accélérer la requête. Mais aucun optimiseur automatique est infaillible. Pour des requêtes complexes exécutées fréquemment ou manipulant de grandes quantités de données, modélisez prudemment votre requête. Utilisez l'option SET PLAN avec l'outil ISQL pour tester les requêtes, constater leurs performances et quel plan de requête choisit l'optimiseur.

Interbase V4.0, V4.1 et V4.2 ont quelques bogues connus, par exemple les requêtes utilisant la syntaxe JOIN en langage SQL ANSI 92 ne sont pas parsées et optimisées correctement. Évitez cette syntaxe ou si vous devez l'utiliser, spécifiez votre propre plan de requête.

Interbase maintient son propre cache des pages de données en cours d'utilisation dans la RAM du serveur. La taille du cache par défaut est de 75 pages pour la V4.0. Avec la V4.2, on passe à 256 pages (qui sont partagées par tous les clients se connectant à la base). Pour une base de données avec des pages d'un Kilo octets, cela représente seulement 256 Ko. La plupart des serveurs comportent beaucoup de mémoire, autant l'utiliser ! Tentez de passer le cache de sa valeur par défaut de 256 pages à un nombre de 10 000 pages par base. Vous constaterez alors une diminution des temps de réponse, l'expérimentation vous le confirmera.

Il y a plusieurs avantages à effectuer régulièrement des sauvegardes et restaurations d'une base Interbase en utilisant l'utilitaire GBAK :

• reconstruire les index ;
• supprimer les versions d'enregistrements obsolètes (« garbage ») ;
• défragmenter les pages de données de la base ;
• réécrire les tables séquentiellement ;
• effectuer une sauvegarde de vos données.

Les fonctions utilisateur (UDF), déclencheurs (triggers), procédures stockées et procédure de sélection peuvent permettre à votre base de données d'exécuter un nombre non négligeable d'opérations sur le serveur, probablement plus puissant qu'une station cliente. Cette technique évite aussi un trafic réseau superflu. Référez-vous à la documentation (Lisez « InterBase Programmer's Guide » et « Data Definition Guide ») pour des détails sur les fonctions UDF, triggers et procédures stockées.

La plupart des OS présentent des fonctionnalités de cache ou des tampons d'entrées/sorties disques. Cela permet aux programmes de placer les écritures disque successives vers le cache situé dans la RAM du serveur. Le système d'exploitation prendra en charge l'écriture régulière du contenu du cache sur le disque dur. En économisant l'écriture de petites quantités sur disque et en les rassemblant en une écriture globale, on augmente généralement les performances d'entrées/sorties de façon significative.

L'emploi du cache disque est quelquefois appelé « entrées/sorties asynchrones » ou « écritures cachées ». Supprimer le cache et forcer les opérations d'entrées/sorties pour écrire directement sur le disque est appelé « entrées/sorties synchrones » ou « écritures forcées ». Les I/O asynchrones ont l'avantage de donner des performances plus hautes, mais la RAM est un support de stockage volatile et des données peuvent être perdues en cas d'une baisse de tension ou si le serveur plante ou redémarre sans avoir transféré le cache sur le disque. Les I/O synchrones assurent qu'aucune donnée ne sera perdue, mais les opérations d'I/O directes sur disque sont plusieurs fois plus lentes que l'écriture en RAM. Un choix à faire après des tests sur chaque base et dans chaque contexte.

Interbase permet aussi bien les entrées/sorties asynchrones que synchrones. La commande GFIX -WRITE SYNC MYDATABASE.GDB utilise l'écriture forcée des données (synchrone). La commande GFIX -WRITE ASYNC MYDATABASE.GDB utilise le cache (asynchrone).

Les entrées/sorties asynchrones peuvent augmenter de beaucoup les performances d'Interbase, mais des mesures devraient être prises pour prévenir une perte de données. Par exemple, utilisez le disk mirroring (disque miroir) pour conserver une copie des données ou travaillez en RAID 5. Aussi, prévoyez un onduleur garantissant une stabilité d'alimentation électrique du serveur. Avec de telles mesures, on peut tirer profit des entrées/sorties asynchrones sans sacrifier la sécurité.

TCP/IP est un protocole réseau plus rapide que SPX ou NETBEUI.

Se connecter à votre réseau ou serveur Windows NT via TCP/IP donnera de meilleures performances.

Le service NETBEUI passe en basse priorité sur les serveurs NT, et il y a un moyen dans le système d'exploitation de monter cette priorité. Certains utilisateurs rapportent avoir obtenu une performance accrue avec ce moyen.

Référez-vous à votre documentation NT pour savoir comment changer la priorité des services NETBEUI.

NOTE : à partir de Windows NT4, la performance de l'implémentation NetBEUI Microsoft a été améliorée. Elle est maintenant au moins aussi bonne que l'implémentation TCP/IP Microsoft. Cependant, sur un réseau encombré, NetBEUI trouve ses limites en ce sens qu'il est un protocole sans connexion. Ce qui veut dire que chaque hôte sur le réseau doit écouter chaque paquet et en vérifier le destinataire. Plus il y a d'hôtes accessibles sur le réseau, plus chacun d'eux doit gérer un nombre croissant de paquets ne lui étant pas destinés.

UNIX est plus rapide en multitâche que Windows NT ou NetWare, même avec du matériel identique, mais cela dépend des versions de chacun de ses OS. Si la rapidité est un critère de choix, penchez pour un serveur UNIX. Si vous avez du matériel de type Intel, SCO UNIX peut s'exécuter sur la plupart des plateformes Intel.

Novell NetWare peut être employé comme serveur de fichiers en plus d'un serveur Interbase, mais dans ce cas, le manager de verrous réseau ne donne pas le premier rôle à Interbase, mais au service des fichiers. Le résultat est que tandis que les utilisateurs lisent et écrivent des fichiers sur la même machine qui fait tourner Interbase, les performances d'Interbase souffrent d'une dégradation. La solution est d'installer Interbase sur un serveur dédié, qui ne fasse pas office de serveur de fichiers. Sur serveur NT, le serveur est configuré par défaut pour donner la priorité aux services de partage de fichiers. Vous pouvez changer cette configuration en passant par :

Panneau de configuration à Réseau à Logiciel réseau installé à Configurer.

Sélectionnez « balance ou serveur de bases de données ». Cela peut entraîner un accroissement important des performances d'Interbase.

Par défaut, Interbase a une fonction intégrée qui nettoie automatiquement les vieilles versions des enregistrements lorsqu'ils deviennent trop nombreux. L'inconvénient de cette méthode est que si elle est démarrée par malchance par une transaction cela aboutit à une surcharge de travail pour le « nettoyage » de la base. Le processus client ralentit durant l'opération. Désactivez le garbage collector automatique (avec la commande GFIX -h 0) au profit de nettoyages de base programmés (commande GFIX -s) cela évitera de perturber les performances du client.

Effectuer à bon escient un backup et un restore donne le même résultat qu'un nettoyage complet de la base. Un backup sauvegarde uniquement la version la plus récente de chaque enregistrement. Il ne sauvegarde jamais les anciennes versions. Ainsi quand les données sont restaurées, il reste seulement une version pour chaque enregistrement restauré. Il y a aussi d'autres avantages à sauvegarder et restaurer régulièrement (cf. plus haut dans ce document).

En parlant du garbage collector, pas mal de programmeurs ne réalisent pas qu'il faut démarrer (START) et valider (COMMIT) leurs transactions sur une base Interbase. Ouvrir une transaction prévient d'un nettoyage périodique du ramasse-miettes, les performances se dégradant progressivement à chaque fois. (NDT Je ne vois pas ce sur quoi l'auteur a voulu mettre l'accent.)

Modelez votre base en normalisant correctement les données. Les enregistrements qui ont beaucoup de groupes de champs répétés sont plus larges qu'ils n'en ont besoin. De larges enregistrements peuvent accroître le coût des tris, et aussi étendre les enregistrements sur plus de pages que nécessaire, aboutissant sur plus de pages fragmentées, et de gros fichiers disque, le tout sans aucune utilité.

Concevez votre application de façon à ce qu'elle valide les transactions aussi vite que possible après les avoir démarrées. Souvent les développeurs démarrent une transaction et ensuite affiche une interface utilisateur de saisie des données. Obtenez plutôt les données de l'utilisateur dans un premier temps, et seulement alors démarrez une transaction pour insérer les données et les valider dans la foulée.

L'objectif est de raccourcir la durée des transactions, réduisant la probabilité que deux applications concurrentes butent sur un enregistrement commun verrouillé. Cela évite aussi beaucoup de trafic réseau et de ROLLBACKs, puisque c'est votre application qui décide quand soumettre des données et quand s'en débarrasser et non l'utilisateur.

Il est assez facile de comprendre que plus il y a de middlewares, moins les performances sont bonnes. Donc, on en conclut (et on peut le vérifier souvent) qu'une application Delphi ou C++ Builder qui utilise directement les API de Interbase via sa DLL cliente est plus rapide que son équivalent utilisant le BDE.

Toutefois, méfiez-vous des fausses portes ouvertes et des raisonnements trop limpides comme ceux-ci… Il faut du doigté et… des tests pour trancher un cas particulier.

Et tous les cas sont particuliers…