Salut,

quelqu'un a déjà optimisé une appli JEE ici ?

dans un numéro de Le Monde Informatique, le responsable d'un département informatique racontait comment ils avaient optimisé leur application Java en la réécrivant en C.

Non, je n'ai jamais optimise d'application JEE. Mais j'imagine que ca s'optimize comme toutes les applications. Trouves l'operation qui prend le plus de temp et fait la aller plus vite.

C'est exactement ça... Une application est oujours lente pour une raison. Et c'est rarement le langage utilisé qui est le bottleneck.

Dans certains cas la raison de la lenteur est incontournable dans le langage. Mais si tu ne sais pas optimiser ton application, la raison n'est certainement pas liee au langage.

LOL oui je sais qu'il faut trouver les goulots mais c'est vraiment pas aussi simple que je le pensais.

J'arrive en stage, jamais fait de JEE (mais bcp de Java, pas mal de SQL, JDBC) ma mission : optimiser une bonne appli JEE (ce n'est pas moi le créateur) qui tourne en prod.

Ben c'est vraiment pas simple, surtout quand l'architecture est complexe et que le code n'est pas le vôtre.

J'en ai déduis plusieurs opit possibles :
-indexs sur les tables des BD + scripts de planif (en cours)
-mis en cache de JDBC avec EHCache (fait et OK)
-passer les EJB remote en EJB locaux (quelqu'un l'a t'il déjà fait ? c'est simple ?)
-déplacer les requêtes SQL qui sont placée dans une table de la base, dans un fichier de config (l'appli doit doit accéder à la BD pour trouver les requêtes qui vont lui permettre d'aller accéder à la BD... c'est le serpent qui se mord la queue)

J'utilise Youtkit Java Profiler pour monitorer l'appli et j'avoue il m'es fort utile
Grâce à lui j'ai déjà pu identifier les requêtes gourmandes et je les ai mise en cache (10000appels => 2000appels )

Ma question : pour mettre en tâche planif des requetes SQL faut juste utiliser l'Agent de SQL Server ?

Quand tu fais de l'optimisation pense bien a faire toutes tes evaluations sur un service charge comme la prod l'est. (Bien sur pas sur le serveur de prod directement.) Il est classique que les goulot d'etranglement change en fonction du workload. Du coup tu peux te retrouver a optimiser quelquechose qui ne coute pas cher en pratique. Ou pire, quand on optimise on echange souvent une diminution d'un cote pour une augmentation de l'autre (moins de calcul plus de memoire; moins d'access a la base externe plus de cache...)

Oui mais dans ce que tu me cites moi ça me va. Plus de cache c'est ce qui faut car en théorie les accès au cache coutent beaucoup moins que ceux à la Base. Et plus de mémoire ça me va aussi, sachant que le serveur va passer en virtuel d'ici fin Juillet et donc qu'on pourra lui attribuer autant de RAM que nécessaire.
Sinon pour le reste j'avoue que c'est pas évident, d'autant plus que je bosse sur une copie de l'appli que je fais tourner sur mon ordi...
Donc oui les résultats ne sont pas les mêmes (les temps de chargement de l'appli sur ma machine sont en général + longs que sur le serveur) mais je suppose que le comportement de l'appli reste le même d'une machine à l'autre (normal) et il faut bien que je bosse sur quelque chose..

L'application date de 2008 et il y a eu quelque erreurs de conception que j'ai identifiées et que j'ai jugé à corriger (comme les requêtes dans la Base, pas de système de persistance c'est du JDBC pur, EJB qui à distance alors qu'ils pourraient être en local ça couterait moins de ressources etc etc...)

C'était soit corriger ces erreurs soit réécrire tout l'interface qui a été fait forcément avec un framework aujourd'hui assez dépassé (EXT JS 2.1) mais ça ça me bottait beaucoup moins