Olivier et la performance Java

Quelques commentaires suite au blog
d’Olivier Rafal sur la Performance Java
:

Tout d’abord, une petite précision, “Barcelona” est le nom
de code du projet MVM et à ma connaissance mes
collègues espagnols ne sont pas impliqués.

Ensuite, la performance, on cours toujours après et comme
pour la sécurité, si on ne se fixe pas d’objectif
à atteindre, on peut toujours courir. Nos clients
réclament toujours plus de performance et c’est normal.
Parmi les avancées récentes (outre la vitesse des
processeurs), il y a les JVM 64-bit qui permettent de
dépasser les 2Go ou 4Go habituels avec les JVM 32-bit (ok, tout le monde n’est pas concerné).

Il existe plusieurs benchmarks publics sur les “performance java” et
les résultats montrent des améliorations
impressionnantes simplement en passant à une JVM plus
récente. Le message est donc d’utiliser ce qu’il y a de plus
récent pour améliorer à moindre frais
la performance. Sun travaille pour vous!

A noter qu’à partir du JDK 5.0, la JVM propose un partage
des classes système pour améliorer  le
temps de démarrage (un paramètre de “performance”
parmi bien d’autres). Pour les détails: %
java -Xshare
.

Pour en venir à MVM
(Barcelona ou Multi-Tasking Virtual Machine pour ceux qui suivent),
la  performance est un objectif avoué, mais elle
prend plusieurs formes. En faisant cohabiter plusieurs applications
dans le même processus, on essaye de partager tout ce qui est
partageable (pas seulement les classes système). L’objectif
est de minimiser le temps de démarrage des applications Java,
mais aussi le nombre de classes total chargées en
mémoire. Aujourd’hui chaque application Java travaille sur
sa propre copie de classes système par exemple.

Faire de la consolidation d’applications Java c’est bien, mais comme
pour toute consolidation, il ne faut pas perdre en
sécurité ou en qualité de service. MVM
propose donc deux API, une pour gérer les isolats et une
autre pour la qualité de service. Les domaines d’application
de MVM sont assez naturellement l’embarqué (J2ME) ou la
mémoire est une denrée rare, mais aussi le poste
de travail (J2SE) pour des démarrages plus rapides et enfin
J2EE essentiellement pour les aspects qualité de service de
MVM (on sait déjà héberger plusieurs
applications J2EE dans une seule instance de serveur d’application).

Je ne sais pas très bien à quoi correspond
l’information sur J2EE 1.3.1 (pas ce qu’il y a de plus
récent) dans la niouze
citée par Olivier.

Pour commenter plus précisément le blog
d’Olivier
, les
problèmes de performance existent et leur sources sont
multiples: problème hardware (rare), problème OS
(besoin de d’optimisation), problème JVM (besoin
d’optimisation), problème architecture ou app server,
problème applicatif. Plus on monte dans les couches, plus la
probabilité de trouver un problème est grand, plus
le potentiel de gain est important et plus le coût d’une
modification est élevé (modifier l’architecture
d’une application coûte très cher). Les
problèmes de performance sur des architectures n-niveaux
sont souvent le résultats de problèmes d’attente
de ressources (réseau, SGBD, etc…) ce qui n’est donc pas
lié à Java directement.

Les problèmes de performance peuvent donc survenir (n’allez
pas dire à mes collègues de notre centre de
benchmark qu’ils n’existent pas), mais ils sont de moins en moins
fréquents et surtout de plus en plus transparents pour les
développeurs. En particulier, le ramasse-miettes (Garbage
Collector) fait depuis longtemps office de bouc émissaire
idéal. Or, quand on mesure son temps d’exécution
(avec JConsole
fournit avec le JDK 5.0
par exemple), on trouve habituellement quelques % du temps
d’exécution global ce qui signifie que même si on
ramène son exécution à 0, on ne gagne
que quelques %.

L’objectif de Java n’est pas de “remplacer le parc
applicatif patrimonial”
et la
performance n’est d’ailleurs pas du tout un problème, voir
plutôt du coté “résistance au
changement”, “coût de re-développement”, “impossible de calculer un ROI”, etc…

Pour le commentaire de Sam sur SWT, je ne suis évidemment
pas d’accord ;-)

Ceci étant, je suis preneur
de questions et commentaires sur le sujet java et performance qui n’est
pas un sujet tabou chez Sun!

Pour ceux qui veulent encore lire sur le sujet:


http://java.sun.com/performance/


The Tale of Java Performance (pour les assoiffés)




MAJ: Bon, tout ca est bien décousu… la morale de cette longue histoire est que ce qui est le plus difficile aujourd’hui, c’est de bien dimensionner un système et que la performance n’est plus une préoccupation pour le développeur.



“Je vous écris une longue lettre parce que je n’ai pas le temps d’en écrire une courte”, Voltaire.



Author: alexismp

Google Developer Relations in Paris.

2 thoughts on “Olivier et la performance Java”

Comments are closed.