Discussion :

[Jacques - 06]

Nous avons développé une application J2EE à base de Struts / OJB. Cette application est actuellement en production chez plusieurs clients et nous sommes en phase de dimensionnement pour un de ces clients qui déploie celle-ci sur un Weblogic 8.1 sp2 sous Windows.

Nous avons donc lancé une campagne de benchmark et nous rencontrons un seuil au delà duquel nous n'arrivons pas à augmenter le nombre d'utilisateurs simultanés (jusque là tout est normal me direz-vous).
Le problème vient du fait que à la valeur seuil, le serveur n'utilise qu'environ 40% de la puissance CPU (il s'agit d'un serveur bi-pro avec Hyperthreading sous 2003), même si la charge est bien répartie sur les 4 CPUs virtuels.

On a donc atteint un goulet d'étranglement au niveau du traitement des requêtes en entrée (mais pas forcement au niveau HTTP). J'ai commencé à tester une augmentation du nombre de thread Weblo et le tir est en cours.

Par contre sur Websphere, dans ce cas de figure, IBM recommande la mise en place d'un cluster vertical, configuration que nous avons validé avec des gains de performances pouvant dépasser le facteur 2 sur un m^me serveur physique.

Ma question est : avez-vous déjà été confronté à ce type de problème, et si oui que faut-il modifier dans la configuration de Weblogic pour diminuer ces points de contention (il y a bien une doc de tuning Weblo, mais rien ne vaut une expérience terrain) ? Quelqu'un a-t-il expériementé la mise en oeuvre d'un cluster vertical (plusieurs serveurs Weblogic sur un même serveur physique) et peut-on espérer les mêmes gains qu'avec Websphere ?

Jacques Desmazières

[tesla]

Salut,

Qu'avez vous passé comme arguments au démarrage de Weblo ?
En particulier la valeur du paramètre MaxPermSize ?

[Jacques - 06]

La seule modification que nous ayons faite au script de lancement est la suvante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET MEM_ARGS=-Xms256m -Xmx1024m -XX:MaxPermSize=128m

Après le test, j'ai constaté qu'en augmentant le nombre de threads (passer de 25 à 40) j'avais plutôt dégradé les performances. Paradoxalement j'ai même de meilleurs résultats avec un serveur de dev qu'un serveur de prod. Mais là je soupsonne grandement un problème de configuration du serveur de prod !

Jacques Desmazières

[tesla]

Essaye en mettant :
-XX:MaxPermSize=256m sinon avec -XX:MaxPermSize=384m

La valeur de -Dweblogic.ProductionModeEnabled est elle bien à true ?
Quelle est la valeur du paramètre Servlet Reload ?

[Jacques - 06]

-XX:MaxPermSize=256m sinon avec -XX:MaxPermSize=384m

Je vais essayer ces options

-Dweblogic.ProductionModeEnabled

J'ai fait le test avec et sans pour un même résultat.

Quelle est la valeur du paramètre Servlet Reload

A quoi correspond-il et comment j'y accède ?

Jacques Desmazières

[tesla]

Re,

Hmm...ca m'étonne beaucoup que l'activation du mode production ne change rien. D'ou la necessité de vérifier le paramètre "Servlet Reload".

Ouvrir la console d'admin et dérouler l'arborescence décrivant le serveur jusqu'a la web app. Cliquer sur la web app concernée. Dans la frame de droite, on doit voir s'afficher un onglet "Configuration". Cliquer dessus puis sur le sous onglet "Descriptor". Chercher un paramètre nommé "Servlet Reload Check Secs". Sa valeur doit être égale à -1 en mode production. Il faut redemarrer le serveur pour valider cette modification.
Si la valeur de ce paramètre n'est pas à -1, il va passer beaucoup de temps à vérifier si la version de la Servlet à traiter a changée depuis le dernier accès.

Un pendant de ce paramètre existe au niveau jsp. Editer le fichier weblogic.xml situé logiquement dans le répertoire WEB-INF de la web app.
Le paramètre pageCheckSeconds doit être à -1 aussi. Comme ça :

<jsp-descriptor>
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>-1</param-value>
</jsp-param>
</jsp-descriptor>