En moyenne, le nombre d'applications J2EE qu'exploitent les 230 grands comptes Java récemment sondés par Wily Technology s'élève à 210. En 2003, une étude similaire avait relevé une moyenne de 18 applications J2EE par entreprise. Cette progression pose la question de la montée en charge des serveurs d'applications. Pour y répondre, deux options s'offrent aux architectes : le recours aux grands serveurs multiprocesseurs symétriques, ou la mise en grappe de serveurs à petit facteur de forme. Le choix obéit davantage à des impératifs de gouvernance qu'à des considérations de performances. Il est vrai que les serveurs d'applications savent s'adapter à ces deux modèles. Ainsi, le gestionnaire de déploiement de Websphere sait gérer la multi-instanciation de façon verticale (en créant plusieurs instances Websphere dans une machine physique SMP) ou horizontale (avec une instance Websphere sur chacun des noeuds d'un cluster). Par ailleurs, le monitoring des performances J2EE se pose en des termes identiques pour les systèmes Unix et les grappes Windows ou Linux. Pour matures que soient ces architectures, les fabricants n'en continuent pas moins d'en repousser les limites. Ainsi en est-il du clustering. Les noeuds d'un cluster J2EE sont connectés par des liens LAN, et la répartition des sessions est assurée par des équilibreurs de charge ou par le noeud maître du cluster. Désormais, certaines évolutions autorisent le déploiement de clusters J2EE sur des distances hectokilométriques. BEA a ainsi ajouté à Weblogic Application Server 9 des fonctions de réplication synchrone et asynchrone, assurant la réplication de sessions transactionnelles sur des noeuds distants.

Quant au multiprocessing symétrique, on a fait grand cas des techniques de partitionnement logique, grâce auxquelles des domaines applicatifs peuvent être isolés les uns des autres. Il reste que le SMP pourrait, à l'avenir, être adapté d'une autre façon au service d'applications. En effet, la popularité croissante des serveurs SMP en lames conduit BEA à travailler sur l'idée d'une exploitation directe des lames par le serveur d'applications. Ces recherches, qui reviendraient à dédier du matériel au service d'applications, trouvent ainsi un écho dans les travaux d'Azul Systems. Avec son concept NAP (Network Attached Processing), cette start up propose de déporter les traitements Java sur une appliance à processeur multicoeur. Afin d'optimiser les traitements, Azul a amélioré les algorithmes de « ramasse-miettes » de sa machine virtuelle.

A travers ce concept, la société cible, à sa façon, un problème récurrent de l'optimisation de Java en environnement SMP. Sun s'y était attaqué, en mettant en oeuvre, au sein de sa machine virtuelle Hotspot, un garbage collector ( « ramasse-miettes » ) parallélisé, qui accélère le nettoyage des espaces mémoire partagés. Ce type d'améliorations apportées aux JVM ne fait qu'illustrer la diversité des actions correctives applicables dans le cadre d'une optimisation. Celle-ci ne s'arrête pas à la phase de qualification des applications.

Les exploitants avec leurs outils de diagnostic J2EE, tels Wily Introscope ou Mercury Diagnostic for J2EE, ont aussi leur mot à dire. Et de fait, la mise en oeuvre de serveurs J2EE témoigne d'une évolution des pratiques, puisque des équipes réunissant architectes, développeurs, testeurs et exploitants se rassemblent autour d'un objectif commun : l'optimisation des performances.