fsmrel

_________________________________________

Je rapporte ici une anecdote concernant un banc d’essai effectué en 1987 (cela fait maintenant un paquet d’années...) par une société américaine réputée pour son sérieux.
Un article parut à ce sujet (Le Monde Informatique du 21 septembre 1987) :

DB2 en transactionnel lourd : des problèmes de performance

Selon cet article, la société américaine en question avait rendu un verdict très sévère concernant le SGBDR DB2 d’IBM (DB2 version 1, release 2), en insistant sur le fait que, à l’occasion du banc d’essai, il s’était révélé que le mauvais débit transactionnel était la conséquence d’un système de verrouillage trop rudimentaire, pas assez fin (verrouillage au niveau de la page, le verrouillage ai niveau de la ligne étant devenu possible seulement fin 1995, avec la version 4 de DB2).

Il y était fait mention qu’IBM citait de son côté le cas d’un utilisateur danois parvenant à un débit de 62 pages/seconde, alors que selon les propres tests de la société américaine, ce débit ne dépassait 18 pages/seconde.

Comble de la honte pour IBM : soumis au banc d’essai, le SGBD quasi-relationnel (sic !) Datacom/DB d’ADR dépota pour sa part à 36 pages/secondes, pour une consommation CPU près de 4 fois plus réduite que celle de DB2.

Conclusion évidente : IBM racontait n’importe quoi et devait manifestement revoir son système de verrouillage...

Mais... Un mois après la parution de l’article, Ted Codd (père du Modèle Relationnel de Données) et Chris Date (le plus ardent défenseur du Modèle) vinrent à Paris, animer un séminaire au Palais des Congrès, du 29 septembre au 2 octobre 1987. L’introduction à ce séminaire fut faite par Sharon Weinberg (devenue Sharon Codd 3 ans plus tard), qui avait eu chez IBM la responsabilité technique de la première version de DB2 et nous l’appelions affectueusement Madame DB2. A un moment donné, Sharon cita les tests effectués par l’utilisateur danois sans oublier les 62 pages/seconde et je sursautais, car j’avais en mémoire l’article du Monde Informatique. Lors de la pause, avant que Chris ne prît la parole, comme j’avais encore cet article dans ma besace, je me dépêchai de le mettre sous les yeux de Sharon, qui me promit de tirer tout cela au clair : pensez, son bébé attaqué ! La désinformation en action ! Elle fit une photocopie du papier litigieux et me fit part en fin de journée des résultats de l’enquête qu’elle s’était empressée de faire :

Les informaticiens de la société auteur du banc d’essai étaient des spécialistes de longue date de Datacom/DB, mais totalement novices en DB2, et l’ayant installé trois semaines avant d’entamer le fameux banc d’essai. Fermez le ban !

Quelques commentaires personnels :

Effectuer un benchmark nécessite une grande compétence pour chacun des SGBD concernés, ce qui en l’occurrence n’était absolument pas le cas.

Il ne faut pas se laisser impressionner par le sérieux d’un article et par la carte de visite du testeur pour tenir comme crédibles des conclusions prétendument imparables, mais révélatrices d’une légèreté coupable.

A la lecture de l’article, j’aurais dû avoir la puce à l’oreille, ne serait-ce que par le label de "quasi-relationnel" que son auteur a accordé à Datacom/DB : soumis deux ans plus tôt aux 12 règles de Codd, permettant de qualifier les SGBD se prétendant relationnels, le candidat Datacom/DB avait obtenu la note peu flatteuse et sans appel de 0 sur 12 (contre 7 pour DB2)...

Concernant la système de verrouillage de DB2, j’eus plus tard la confirmation (et le vérifiai par moi-même chez un de mes clients, chez qui je bâtis un prototype de performances et de concurrence en mise à jour) que ce n’était pas le mécanisme de verrouillage des pages des tables qui était en cause, mais celui des index, ce qui manifestement avait échappé aux testeurs « experts » : une fois identifiée précisément la cause, on pouvait débloquer la situation, mais encore fallait-il un minimum de bon sens, de méthodologie et d’absence de préjugés, à défaut de compétence. Par la suite, j’ai toujours utilisé le verrouillage au niveau page pour les tables, sans dommage pour les applications (bien que, comme je l’ai évoqué, IBM offrît par la suite le verrouillage par ligne, mécanisme qui du reste n’a pas que des avantages. Et puis, les verrous ont été accompagnés de loquets et autres subtilités concourant à libérer au mieux les ressources).

Je n’en veux pas trop au Monde Informatique qui n’a fait que rendre compte, quoique sa conclusion façon « presse du cœur » est un rien subjective et désinformatrice :

« Il est clair que la difficulté de prédire les temps de réponse dans des applications évoluant vers un degré de complexité croissant a de quoi inquiéter les utilisateurs de DB2 »

« Il est clair » ? Vraiment ? Plus prudemment, j’aurais écrit :

« La difficulté de prédire les temps de réponse dans des applications évoluant vers un degré de complexité croissant a de quoi inquiéter, parmi les utilisateurs de DB2, ceux qui sont peu soucieux d’effectuer des travaux sérieux de prototypage »

Je dénonce plutôt l’approche de la société ayant effectué le banc d’essai : savoir prédire les temps de réponse, ça s’apprend, surtout avec un SGBDR et une approche (ensembliste) que l’on ne connaît pas, auquel cas on commence du reste par méditer la proposition numéro 7 du Tractatus de Ludwig Wittgenstein :

« Sur ce dont on ne peut parler, il faut garder le silence. » (Wovon man nicht sprechen kann, darüber muß man schweigen.)

Après Datacom/DB, place à IDMS/R...

Peu de temps après, en ayant assez de voir la société éditrice du SGBD prétendu relationnel IDMS/R passer son temps à vanter les mérites de son SGBD (ce qui est normal) et tirer à boulets rouges sur ce malheureux DB2 (ce qui m’agaçait singulièrement), je procédai durant six mois à une étude comparative très poussée, sous le contrôle de cette société, laquelle fit une drôle de grimace et dut rendre les armes, au terme du compte-rendu de travaux qui ne laissèrent guère de répit à un puissant mainframe que je chauffais à blanc la nuit, durant les heures creuses. Un peu d’objectivité de temps en temps ne fait pas de mal...

Incidemment, je rappelle que, dans son article An Evaluation Scheme for Database Management Systems that are claimed to be Relational (reprenant ses articles parus dans Computerworld en octobre 1985), Ted Codd avait soumis à l’aune des douze règles, 3 SGBD qualifiés de relationnels selon leurs éditeurs respectifs : DB2, Datacom/DB et IDMS/R : comme je l’ai déjà mentionné, 7 sur 12 pour DB2, zéro pointé pour Datacom/DB, même punition, même motif pour IDMS/R. Depuis, ces deux SGBD pré-relationnels ont changé de propriétaire et de nom et sont référencés désormais comme CA-Datacom/DB et CA-IDMS (CA étant l’abréviation de Computer Associates, si vous le voulez, prononcez « Compiouteur à chaussettes », c’est moins difficile...), ils permettent même désormais de faire du SQL...