ous pensiez en avoir fini avec le feuilleton des Benchmarks J2EE vs .NET. Et bien c'était sans compter avec nos joyeux lurons de la Middeware Company. La société vient en effet de publier un document d'une soixantaine de pages décrivant dans les moindres détails les conditions de nouveaux tests en laboratoire effectués sur 4 applications sous la bannière du désormais célèbre PetStore. Le premier Benchmark avait été un véritable camouflet pour le cabinet de conseil qui avait dû essuyer de vives critiques de la part de la communauté Java. En Octobre 2002, .NET était presque deux fois supérieur à J2EE sur la base de codes sources, il faut l'avouer, totalement incomparables (PetShop 2.0 et un PetStore SurPatterné) et les conditions des tests étaient pour le moins hasardeux.  Aujourd'hui les performances sont comparables et Java regagne ces lettres de noblesses. Enfin, presque ...

Cet article vise donc à vous faire une brève synthèse de ce Benchmark tout en y apportant quelques remarques. Nous vous encouragement d'ailleurs vivement à les commenter sans sombrer dans un débat stérile.

Un emballage marketing savamment orchestré 

La première réaction qui nous vient à la lecture de ce dossier concerne l'approche marketing. Le discours a été totalement revu et corrigé. Tout d'abord, le titre. TMC n'évoque plus le terme de "Benchmark" mais de "Case Study". La raison ?  "The term benchmark evokes emotional reactions from people. That is counterproductive." ... "Second, this term implies a more formal structure and process (often with commitees and voting) than that we have" D'aucun dirait que "chat échaudé craint l'eau froide" mais c'est bel et bien l'état d'esprit qui prévaut tout au long de ce Bench. Le terme qui résume le mieux ce document est "politiquement correct". Et c'est peut-être d'ailleurs là le noeud du problème. 

Le discours envers la communauté a changé (plus humble, plus explicatif) mais celui envers les éditeurs également : "Statement such as "J2EE can never win on Windows" because thats Microsoft home turf and they run native" or "Microsoft can't do enterprise applications" can safely be dispelled as nonsenses, especially, with regard to performance". Un moyen élégant pour évoquer l'indépendance et l'objectivité de l'étude.

Pour éviter toute critique, TMC s'est entouré des plus grands spécialistes provenant de chez Oracle, Microsoft et de la société elle-même. Au passage, on peut s'interroger sur la citation des deux experts Oracle qui ont eu droit à un CV des plus détaillés alors que les autres intervenants n'ont même pas eu la moindre référence.

Enfin, la partie la plus étonnante est celle qui concerne le financement du projet. Si les différents éditeurs J2EE ont refusé pour la plupart d'être cités, il en va pas de même pour Microsoft qui tout de même fournit toute l'infrastructure matérielle/logicielle. Quant au laboratoire, il était hébergé à Redmond avec la possibilité pour les différents intervenants du groupe d'experts de participer en qualité de témoins aux différents tests. Tout laisse à croire que Microsoft ait été le principal sponsor de ce projet. L'éditeur pensait sûrement que TMC leur offrirait une formidable occasion de vanter les mérites de sa plateforme qu'elle sait pertinemment supérieure à J2EE (en terme de performances).

La synthèse des tests 

Les résultats sont tout de même étonnants même si on aurait pu s'y attendre (vu le tollé provoqué par le premier Bench). J2EE et .NET font presque jeu égal excepté pour les WebServices ou l'environnement de Microsoft surclasse de presque 200% ses rivaux. Si nous avions déjà évoqué sur DNG cette faiblesse de J2EE, il convient toutefois de prendre avec précautions de tels chiffres eut égard aux implémentations internes des sérialiseurs XML présents dans .NET. Ceux liés aux applications J2EE dépendent du produit utilisé (Axis, Glue, etc.). Difficile de tirer des conclusions lorsque le produit n'est pas cité.

En revanche, plus surprenant, le fait qu'il existe d'importantes différences entre serveurs d'application Java. Une application à base de composants EJB (Session/Entités CMP 2) et une autre sans EJB ont été testées. Nous vous conseillons vivement de lire le duel "Application Server X vs Application Server Y" (apparemment WebLogic vs Oracle 9iAS). Un guide des bonnes pratiques de tuning.

(copyright TMC)

Les WebServices :

(copyright TMC)

Un document destiné essentiellement à la communauté Java

Lorsqu'on parcourt le document, on s'aperçoit du travail considérable effectué sur le Tuning des serveurs d'application J2EE. C'est d'ailleurs la chose qui nous a le plus stupéfait. Au lieu de rendre les conclusions d'un banal test de performances, TMC a réussi à transformer ce document en un véritable hymne au Tuning. Finalement, un moyen absolument imparable de détourner le débat principal et miné "J2EE vs .NET" vers un débat sur "Comment tuner les serveurs d'application grâce à TMC". Imparable et ne souffre d'aucune contestation si les tests n'avaient pas été menés par un groupe de spécialistes dont la plupart ne font d'ailleurs pas partie de TMC. Sans compter que sur 60 pages, seules 3 pages traitent réellement du travail effectué par Microsoft sur le PetShop en terme de Tuning. Apparemment rien de bien extravagant, une entrée de la base de registre à modifier et quelques paramètres COM+ à adapter (la taille des Pools). Soit le document est totalement disproportionné, soit le tuning de .NET a véritablement été un jeu d'enfant. On aurait préféré plus de détails sur cet aspect des tests mais on ne peut non plus trop en demander à une société essentiellement axée sur les technologies J2EE (quid des paramètres de la CLR ? Pile/Tas ? Threads ? I/O ?)

Conclusion

Il faut se rendre à l'évidence, ce Benchmark, aussi sérieux soit-il continue à comparer des carottes et des bananes. Aujourd'hui, ASP.NET fournit avec les WebForms un Framework n'ayant aucun équivalent côté Java. Créer à chaque postback un arbre entier de contrôles serveurs avec la sauvegarde automatique de l'état (ViewSate) est une opération très coûteuse. D'ailleurs vous aurez noté que lorsque Struts est évoqué côté Java, les remarques négatives fusent aussitôt car les performances chutent du fait des opérations de Reflection et de mapping entre flux HTTP et Beans.

Quels auraient été les résultats finaux si le PetShop .NET n'avait pas été basé sur les WebForms ...

Finalement les Benchmarks les plus fidèles sont ceux qui s'attachent à comparer des points précis (boucles, accès aux données, lecture d'un fichier, etc.) car ils mettent en oeuvre des API très similaires et atomiques. Les autres souffrirons toujours des différences existantes entre les environnements .NET et Java en attendant JSF (Java Server Faces).

Si ce Bench est beaucoup plus instructif pour le développeur Java que pour le décideur .NET, il a le mérite d'exister. Alors ne vous privez pas d'un fabuleux cours sur le tuning et les entrées/sorties en Java, téléchargez cette étude...