Nombreux sont ceux ?” éditeurs bien sûr, mais aussi analystes ?” qui prétendent que la banalisation des serveurs d’applications J2EE (Java 2 Enterprise Edition) est telle qu’ils mériteraient d’être qualifiés de “commodités”. Le prix serait leur seul critère de différenciation. De surcroît, soumis à la batterie de tests de Sun destinée à vérifier leur compatibilité à la plate-forme J2EE, il serait d’autant plus aisé de conclure que les produits certifiés conformes se valent tous peu ou prou. Pourtant, l’expérience des utilisateurs renvoyant un tout autre écho, 01 Etudes et 01 Réseaux ont décidé de réaliser un banc d’essai ?” parfaitement indépendant ?” des principaux serveurs d’applications J2EE. Il existe, en effet, de nombreux critères de distinction des serveurs d’applications en dehors du seul respect de la plate-forme J2EE.
Évaluer la vraie puissance des conteneurs d’EJB
Les caractéristiques des middlewares sous-jacents, les outils de développement et d’administration constituent quelques-uns de ces critères. Ce test était d’autant plus justifié que, hormis les annonces marketing des éditeurs ?” BEA, IBM ou encore Oracle ?” vantant les performances de leurs serveurs d’applications respectifs, il devenait indispensable d’y voir plus clair. Et ce, en commençant par évaluer la réelle puissance de leur conteneur d’EJB (Enterprise JavaBeans). De fait, bien que les EJB soient encore très peu utilisés, la plupart des cabinets d’analystes américains ont pronostiqué une utilisation croissante de ce modèle de composants par les entreprises pour construire leurs applications de production.Pour mesurer les performances des serveurs d’applications J2EE, 01 Etudes a fait appel à la société AlphaCSP. BEA Systems, Borland, HP, IBM, Iona Technologies, iPlanet (filiale commune de Sun et de Netscape), Oracle et Sybase ont été conviés à participer à ce banc d’essai. AlphaCSP a choisi de baser ses tests sur l’application proposée par ECperf (voir encadré), le benchmark officiel présenté par Sun et ses partenaires lors du dernier salon JavaOne, et destiné à mesurer les performances des solutions conformes à J2EE. ECperf a été conçu dans le souci de refléter les problèmes concrets d’entreprise. Il inclut donc les quatre principaux domaines fonctionnels d’une application e-business complète : gestion des clients (prises de commandes…), gestion des fournisseurs (passation de commande, réception des produits…), production et gestion de l’entreprise. Le Giga Group a depuis confirmé qu’ECperf constituait, à ce jour, le seul banc d’essai objectif pour les serveurs d’applications Java. Sur les huit éditeurs conviés, seuls iPlanet et Oracle ont décliné l’invitation en raison d’un manque de ressources. Les six autres ont subi le banc d’essai ECperf durant l’été 2001, de mi-août à fin septembre. Chaque éditeur disposait d’une semaine pour passer les tests, les deux premiers jours étant consacrés à la configuration de leur serveur d’applications et les trois suivants aux tests proprement dits. Cinq configurations de tests étaient prévues afin de pouvoir mesurer les caractéristiques de montée en charge des serveurs d’applications en cas d’ajout de processeur (1, puis 2, puis 4) ou de machine serveur (1, puis 2, puis 3).
Un test ” raté ” mais pourtant instructif
En guise de conclusion majeure du banc d’essai de 01 Etudes-01 Réseaux : une mauvaise surprise. Les éditeurs s’opposent à la publication des résultats. Les serveurs d’applications, placés au c?”ur même des nouvelles infrastructures logicielles des entreprises, semblent donc trop stratégiques pour que leurs fournisseurs, bataillant sur un marché encore jeune et âpre, acceptent la divulgation de résultats neutres. La licence d’utilisation d’ECperf indique, en outre, que toute publication de résultats doit être auparavant soumise au conseil ECperf réunissant les principaux éditeurs. Ceux ne figurant pas en bonne place au banc d’essai n’avaient donc aucun intérêt à rendre public le verdict. Le vainqueur a ensuite agi de même, car privé de tout point de comparaison. Cette absence de bilan chiffré n’empêche cependant pas de retirer de riches enseignements de ce test ” raté “.Premier constat : ECperf est tout sauf mature. Les tests ont permis de découvrir que son modèle mathématique n’est absolument pas déterministe. Ce qui conduit à ne pas obtenir les mêmes résultats lorsque l’on passe un même test plusieurs fois. De plus, ECperf exige la vérification d’un certain nombre de critères statistiques sur les temps de réponse, les taux de succès des requêtes des utilisateurs, etc. Or, pour l’ensemble des produits éprouvés, certains de ces critères étaient inaccessibles. De plus, l’interprétation des résultats fournis par ECperf est très complexe pour des non-spécialistes de ce benchmark. L’immaturité d’ECperf est telle que son comité a dû sortir en catastrophe une mise à jour de son application de test suite à ce banc d’essai.Le deuxième enseignement de ce banc d’essai est que les serveurs d’applications ne sont pas du tout équivalents et que le réglage de leurs performances est affaire de spécialistes (voir encadré). Pour satisfaire les critères de validation des résultats d’ECperf, les équipes avant-vente européennes des éditeurs se sont révélées totalement incompétentes, principalement par manque de formation. N’ayant pas lourdement investi dans la maîtrise d’Ecperf, ces sociétés ont été incapables de produire des résultats de test acceptables. Même les leaders du marché ont dû faire appel, pour le passage des tests, à leurs experts américains pour obtenir des résultats corrects.Le troisième constat est la linéarité de la montée en charge des principaux serveurs d’applications lorsque l’on ajoute des processeurs ou des machines serveurs dans un cluster. Les performances constatées sur une machine à quatre processeurs ou deux machines à deux processeurs sont très similaires et la gestion du clustering utilise très peu de ressources système.
Des dérives portant atteinte au standard
A la lecture des résultats des tests, on constate également que le respect des standards J2EE n’est pas garanti même pour les serveurs d’applications certifiés conformes à cette plate-forme. Ceci est dû à des imprécisions dans les spécifications J2EE, ce qui conduit immanquablement à des dérives portant atteinte à la conformité au standard. Deux des six serveurs d’applications testés ont présenté des problèmes de compatibilité avec l’application ECperf et, par là même, avec J2EE.Enfin, la dernière leçon de ce banc d’essai tient au rôle même d’ECperf. Cette application a, en fait, été créée pour les laboratoires de recherche des éditeurs de serveurs d’applications qui se battront avec ce nouveau benchmark comme ils se battaient avec le TPC-C pour les moniteurs transactionnels. Toutefois, toute mesure obtenue avec ECperf devra être prise avec des précautions par les directions informatiques, qui ?” par manque de temps, d’argent ou de ressources ?” n’obtiendront jamais le même niveau de performances par leurs propres moyens.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
