Trois exemples

en résultait un salmigondis de rubriques éparses et redondantes. De surcroît, il avait commis la faute magistrale d’utiliser le type REAL au lieu du type DECIMAL pour stocker ses données comptables.

Chaque année, à cause des cumuls, les erreurs d’écart d’arrondis propres au type REAL empêchaient les balances comptables d’être équilibrées et le bilan de s’avérer exact. Il manquait toujours quelques centimes, à droite, à gauche, au milieu et sur les côtés !

N’ayant toujours pas compris pourquoi, il publiait chaque année une "rustine" destinée à corriger ces écarts. Ce processus enfin intégré à sa chaîne de maintenance, il commença de s’attaquer au marché des gros hôpitaux constitué par les CHU… Mais là, les volumes de données n’étant pas les mêmes, les performances commencèrent à se révéler lamentables par la faute du modèle : la redondance comme l’absence de normalisation ayant conduit à l’écriture de requêtes gigantesques, illisibles, ampoulées, inextricables, et, compte tenu du volume, d’une durée exceptionnellement longue.

Finalement l’éditeur était coincé : soit il indiquait à son client que celuici devait prendre un serveur surdimensionné pour pallier au déficit de performance lié à la structure de la base – et dans ce cas il n’arrivait pas à vendre sa solution – soit il la vendait quand même mais se retrouvait en exploitation avec le mécontentement grandissant de ses clients, mécontentement qui alla jusqu’au procès avant qu’il n’abandonnât finalement ce marché pourtant prometteur.

Le second exemple est du même tonneau et curieusement dans le même secteur. On prend une application qui marche, écrite pour Access et on utilise le "wizard", ce magicien d’assistant pour porter son application en SQL Server. Il a suffit de moins d’une heure suivie de deux ou trois corrections et voilà, un produit que ses auteurs croient capable des performances nécessaires et suffisantes pour attaquer les marchés les plus gros, c’est à dire les plus juteux…

Hélas, c’était sans compter sur la perversité de cet assistant – en fait de magicien, une sorcière déguisée – qui a traduit toutes les requêtes à envoyer au serveur, en élément si parcellaires que pour certains écrans, il fallait envoyer plus d’une centaine de requêtes unitaires6. De plus, le logiciel avait été conçu pour scruter certaines données : toutes les secondes pour les unes, toutes les vingt secondes pour les autres, des requêtes étaient lancées sur le serveur pour se renseigner sur l’état de telle ou telle donnée.

Avec une simple projection sur un nombre d’utilisateur potentiel de 50, on arrivait au chiffre pharamineux de 750 000 requêtes lancées en pure perte pendant la période d’exploitation journalière du logiciel sans qu’aucune action humaine sur l’interface n’ait été entreprise !

Le troisième cas est encore plus révélateur : dans une compagnie aérienne, une application de planification était écrite avec un des outils de développement les plus fameux pour son aspect "sapin de Noël" : de clinquant écrans bariolés, agrémentés de multiples objets visuels surchargés de données, clignotant de messages surgissants, permettaient de réaliser le planning des équipages pour la rotation des avions.

Mais les temps de réponse étaient parfois jugés anormaux dans leur durée et cela de manière aléatoire. En fait, chaque fois que le pointeur de souris se déplaçait sur l’écran, des centaines de requêtes étaient envoyées au serveur. Le planning était représenté par de très petites cases dont le temps constituait l’ordonnée et le vol, l’abscisse. Pour se renseigner sur un équipage, les développeurs avaient eu la brillante idée de faire surgir la composition de l’équipage dans une info bulle en allant demander les informations au serveur.

Mais cet appel se faisait à chaque fois que la souris parcourait le moindre pixel à l’intérieur de la case ! Bien évidemment en test cela s’avérait rapide et éblouissant… tout au moins sur un jeu de données plus que restreint. Mais sur une application en exploitation depuis des mois et avec des écrans 21 pouces, l’hallucinant clignotement informationnel mettait à genou un serveur pourtant des plus robustes. D’autant plus qu’encore une fois le modèle de données avait faiblement pris en compte la problématique des données temporelles, qui sont généralement les plus complexes à modéliser et à optimiser.

Tout ces exemples montrent bien comment un système qui a bien marché à un moment donné peu subitement basculer dans la plus sombre des performances sans que l’auteur par son manque de prévision n’arrive à comprendre pourquoi. Dans ces trois exemples, le modèle des données est fortement en cause. Comme il l’est dans tous les audits que j’ai réalisés. Et il est souvent très tard pour rectifier le tir, du fait de l’intense effort à entreprendre pour remanier un modèle de données et le code sous-jacent. Et souvent, au lieu d’entamer une nouvelle version en partant d’un modèle de données sain et performant, on préfère tenter l’aventure de la modification par petite touche, aventure qui finalement n’aboutit que très rarement et s’avère finalement bien plus coûteuse qu’une refonte globale.

Je suis pour ma part effaré par le nombre d’entreprises qui conçoivent des logiciels sans avoir jamais réalisé une analyse et une modélisation de données sérieuse. Si vous avez le moindre doute sur votre éditeur ou sur votre prestataire, demandez- lui le modèle conceptuel de données de l’application. Si vous obtenez quelque chose, ce sera le plus souvent un modèle physique de la base, prouvant que l’analyse des données, c’est à dire l’étude du modèle conceptuel, n’a jamais été entreprise7. C’est la première phase du basculement vers la médiocrité des performances, et la phase la plus cruciale puisqu’il est difficile de revenir sur un modèle bâclé.

Mes audits m’ont conduit à montrer, qu’en dehors des problématiques matérielles, la quantité d’erreurs et les gains potentiels se situaient en premier dans le modèle de données, en second dans l’écriture du code et enfin, dans l’exploitation (un pourcentage négligeable se situant au niveau du serveur SQL et de l’OS). Ce que l’on peut approximativement synthétiser par le tableau 1. NOTA: pour mesurer l’erreur, je me suis servi de mes audits et des points que j’ai relevés, sachant qu’une même erreur située dans plusieurs programmes ne comptait que pour une seule erreur. Assez de discours maintenant, venons en au vif du sujet. Je vous propose de naviguer en ma compagnie dans la matière propre à l’optimisation des bases de données avec SQL Server.

Pour cette navigation, je vous propose différentes escales. D’abord, comprendre le fonctionnement d’un serveur MS SQL Server. Ensuite, de voir en quoi le matériel peut nous aider. Vous aurez compris qu’une étape importante sera constituée par le modèle des données. Puis, nous irons farfouiller du côté du code pour enfin terminer par l’exploitation d’une base de données.

 Tout en sachant que malgré la verve que je compte mettre, nous n’aurons fait qu’effleurer le sujet. Mais, en avant toute, mettons le cap dès aujourd’hui sur les principes de base qui constituent le fonctionnement d’un serveur SQL… En lisant les lignes suivantes, vous allez comprendre l’un des principaux mystères liés aux phénomènes de performance: pourquoi les performances ne sont pas linéaires et peuvent conduire brutalement à un point de rupture… Ou, pour paraphraser monsieur de La Palice, pourtant, ça marchait bien avant !