L'étonnante expérience client-serveur du CEA

L'expérience du CEA en matière de client-serveur, la nouveauté de leur approche, la qualité des résultats qu'ils ont obtenu et le caractère surprenant de certaines de leurs constatations, méritent que les autres informaticiens s'y intéressent. Voici, une par une, les conclusions de Daniel Martin après interview de Gérard Lledo, adjoint au Directeur Informatique du CEA (Commissariat à l'Energie Atomique).

Un downsizing réussi

Lors d'une première application de type data warehouse (aide à la décision avec agrégats pré-calculés) le CEA a réussi à remplacer une base de données DB2 sur mainframe 3090/600 J (un très gros mainframe IBM) par une base de données supportée par un unique serveur SPARCstation 2 (SS/2) avec 9 disques (une simple station de travail avec des disques additionnels) sous SunOS + Sybase. Cette solution client-serveur avec clients Windows coûtait beaucoup moins cher que la solution avec serveur mainframe. Elle était aussi plus performante: une requête qui mettait 50 minutes avec DB2 (en balayage séquentiel) mettait 20 mn avec la SS/2 en parallélisant le traitement. On avait remarqué que le traitement était I/O-bound, c'est à dire que sa durée provenait essentiellement des temps d'accès disques. Le CEA a décomposé les très grandes tables en tables beaucoup plus petites (les "sous-tables"), et chaque requête balayant une grande table en autant de requêtes qu'il fallait pour balayer les sous-tables. Ces requêtes pouvaient être lancées en parallèle et ainsi prendre moins de temps. A la fin, une opération de fusion reconstituait un résultat unique.

Pour obtenir ce parallélisme, il était possible et facile d'utiliser l'architecture Open Client - Open Server de Sybase: le client croit communiquer avec le SGBD Sybase par l'API standard Open Client; en fait, c'est une application "dispatcher" sur-mesure qui reçoit les requêtes avec son API Open Server, effectue leur décomposition en requêtes sur N tables, et passe les requêtes générées à Sybase. Au retour, les résultats sont reçus par le dispatcher qui les met en forme et les passe au client (voir figure). On voit l'intérêt de l'approche Open Client - Open Server, qui permet de créer une application passerelle avec laquelle le client communique de la même manière qu'avec le SGBD; cette application est elle-même cliente du SGBD.

Le mythe du relationnel simple

Fort du succès de cette première application client-serveur, le CEA a réalisé une importante application de production, destinée à la gestion des achats par 1500 utilisateurs, dont environ 250 actifs, avec des clients Windows et un serveur Sun SS/2 sous UNIX avec Sybase. Les programmes, fonctionnellement bons, ont été réalisés par des programmeurs à qui l'on avait dit qu'en SQL "on décrit le résultat à obtenir, pas la manière de l'obtenir, car la manière est l'affaire de l'optimiseur de requêtes". Ces programmes étaient en général inexploitables: à la montée en charge, la performance s'avérait catastrophique. Dans un cas extrême, une requête qui devait s'exécuter (pensait-on) avec une dizaine d'accès disques en demandait environ 100.000! Les programmeurs ne savaient pas résoudre le problème de l'écriture correcte des requêtes. Ce n'était pas la conception physique de la base de données qui posait problème: on avait, en général, fait un découpage en tables correct, dénormalisé correctement et prévu les index qu'il fallait. Aucun cours ne permettait de prévoir comment Sybase optimisait ses requêtes dans des cas particuliers, comment il gérait les conflits d'accès, comment son L4G Transact-SQL gérait certains types de données, etc. Il s'avérait qu'au-delà de quelques dizaines d'utilisateurs simultanés la performance s'effondrait.

Ce n'était pas Sybase qui était en cause (les benchmarks officiels démontraient sa performance) c'était la compréhension de son fonctionnement. Il fallait savoir comment il traitait une requête donnée dans le contexte précis de l'application, pour en déduire comment écrire les requêtes pour qu'il travaille bien. Une première conclusion s'imposait: le slogan "décrivez le résultat à obtenir, pas la manière de l'obtenir" était un piège!

Pour comprendre comment Sybase traitait une requête donnée il fallait un outil spécial: M. Lledo en a imaginé un, baptisé "sniffer". Cet outil, situé conceptuellement entre Open Server et le SGBD, interceptait les requêtes des clients (sans coopération de ceux-ci) et les réponses du SGBD serveur; il dialoguait avec le SGBD pour connaître en temps réel les valeurs de paramètres internes du moteur. Sniffer fonctionnait exactement comme le dispatcher, c'était une passerelle.

Cet outil a permis de comprendre le fonctionnement réel des requêtes SQL/Transact-SQL, puis de les récrire pour qu'elles soient exécutées de manière

optimale. La performance est devenue superbe: aujourd'hui le serveur Sybase supporte 3000 utilisateurs potentiels dont près de 300 actifs, avec un temps de réponse de l'ordre de la seconde.

Un nouveau type d'outil informatique

On avait donc inventé un nouveau type d'outil informatique: un outil de recette. Cet outil vérifiait la qualité des requêtes au sens performance lors d'une recette d'applications.

Le CEA a donc donné l'idée son prototype Sniffer à la société française IMM, qui a réalisé un outil robuste, Cyrano, vendu aujourd'hui dans tout le monde. Cet outil a deux modules: un module de recette, qui analyse le comportement de chaque requête avant mise en production, et un module de production, qui analyse le comportement en charge réelle sans introduire lui-même de surcharge significative.

L'utilisation de Cyrano a permis de résoudre un problème de diagnostic de performance auparavant insoluble. Lorsqu'une procédure Transact-SQL appelle d'autres procédures, qui appellent à leur tour de nouvelles procédures ou des triggers, il est impossible de trouver "à la main" l'endroit où se produit une sur-consommation de ressources ou une attente exagérée sur verrou, car tout va trop vite. Cyrano a donc été muni d'une fonction de trace, qui permet de savoir exactement dans quel ordre les procédures ou triggers sont appelés, comment un deadlock s'est formé, et ce que consomme chaque appel, ainsi que son temps d'exécution. On trouve ainsi les situations de conflit d'accès, les transactions qui utilisent trop de verrous ou durent trop longtemps, etc.

Cette fonction trace s'est avérée si précieuse qu'on lui a adjoint une fonction de statistiques, permettant de déterminer le nombre de fois que l'on accède à chaque table et chaque index, ainsi que la nature (sélection, mise à jour, insertion ou suppression) de chaque accès: on peut ainsi plus facilement optimiser le schéma physique de la base.

Cyrano est désormais utilisé de manière systématique au CEA: toutes les SSII qui développent des applications pour le CEA sont tenues de passer des tests de recette avec Cyrano, pour vérifier la bonne écriture de leurs requêtes Transact-SQL. Cyrano permet même de trouver, dans une exploitation importante où des centaines de procédures stockées tournent en même temps, quelle est la procédure dont la gourmandise excessive freine le serveur.

Le CEA a décidé de passer à la version System 11. La migration vers System 11 a été réalisée successivement:

• en installant d'abord une plate-forme de test distincte de l'exploitation, où les deux moteurs SQL Server 4.9.2 et 11 fonctionnent côte à côte, chacun sur une base à données réelles exportées/importées à partir de la base de production;
• en effectuant une vérification syntaxique sous System 11 des procédures Transact-SQL 4.9.2: il y a eu quelques modifications à faire;
• en écrivant un petit programme qui effectue les tests Cyrano de manière systématique sur les milliers de procédures concernées, et permet la comparaison entre l'ancien comportement et le nouveau;
• en fournissant les rapports de test des procédures aux SSII qui ont une obligation de maintenance: celles-ci ont fait évoluer leurs applications et les ont livrées pour une nouvelle recette, fonctionnelle et avec Cyrano;
• en effectuant des simulations prévisionnelles de charge du moteur SGBD grâce à l'outil V-Test, qui enregistre la manière de travailler d'un utilisateur et génère une charge fonctionnellement équivalente pour un nombre d'utilisateurs aussi élevé que l'on voudra; cette approche a permis de vérifier que System 11 tiendrait la charge, et même au-delà, avec le serveur envisagé (un octoprocesseur SPARCserver 1000 avec 768 MB de mémoire). En l'absence de V-Test on n'aurait pas eu de certitude concernant les temps de réponse, car un serveur fonctionne selon le modèle Markovien (théorie des files d'attente) notoirement non-linéaire... et dont, de surcroît, on ne connaît pas les paramètres.

Cette approche a permis de trouver dans System 11, à part des incompatibilités syntaxiques avec la version 4.9.2, un certain nombre de bogues ou d'insuffisances concernant des mécanismes, comme celui de l'optimiseur de requêtes. Les rapports circonstanciés d'erreur du SGBD ont été transmis quotidiennement à l'équipe de développement de l'éditeur, en Californie, par Internet. Sachant la valeur des tests du CEA et appréciant la pertinence des tests, Sybase a patché en temps réel son SGBD, en général pour le lendemain.

En deux mois, juillet et août 1996, tous les problèmes détectés dans System 11 ont été résolus, et les tests ont montré que la performance serait parfaite: la migration pouvait être effectuée sans danger. Elle a eu lieu sans incident début septembre, malgré les milliers d'utilisateurs concernés et de procédures mises en oeuvre.

Une autre cause de contre-performance des applications client-serveur est la surcharge du réseau. Il est fréquent que des échanges entre client et serveur mal conçus se traduisent par des messages excessifs en nombre et/ou en taille. Il faut donc connaître le volume des communications, échange par échange, comme le permet Cyrano, et en production simulée comme le permet V-Test.

En conclusion:

La méthode de migration du CEA, avec ses tests systématiques des procédures cataloguées, en fonctionnalité comme en performance, permet une vitesse et une qualité de migration encore inconnues à ce jour dans le monde du client-serveur.

On voit que la complexité et l'opacité du fonctionnement d'un SGBD relationnel exigent des spécialistes une compétence en matière de performance qu'ils ne sont pas prêts de posséder, mais que des outils logiciels comme Cyrano et V-Test permettent de remplacer, et au-delà. Les spécialistes concernés sont les programmeurs, les concepteurs et administrateurs de base de données, ainsi que les administrateurs de réseau.