Quelques considérations sur la fiabilité et les performances

des
fabricants sont en mesure de
fournir des statistiques de fiabilité/
disponibilité fondées
sur leur base utilisatrice actuelle.
Dans le choix d’une
plate-forme, il faut aussi
prendre en compte la fiabilité
de l’environnement d’exploitation
: système d’exploitation , middleware et
système d’administration de
la base de données.
L’environnement de la figure
2 utilise des serveurs
Web multiples afin de pallier
la défaillance de l’un d’eux.
WebSphere offre également
un certain degré de tolérance aux
pannes en permettant l’utilisation
d’instances clonées. C’est une fonction
standard de WebSphere Advanced
Edition (5722-WA4) que chaque serveur
HTTP supporte deux clones
WebSphere. Pour cela, l’instance d’application
originale est promue au rand de groupe, puis le groupe est cloné. Le
plug-in WebSphere au serveur HTTP
Apache doit être régénéré pour que le
trafic HTML s’équilibre entre les
clones. Si l’un des clones défaille, le
plug-in redirige le trafic vers les autres.
Le système de communications est
probablement le composant pour lequel
il est le plus facile de prévoir une
capacité suffisante. Mais c’est aussi celui
qui cause le plus d’ennuis. Des
adaptateurs, commutateurs et routeurs
haute vitesse peuvent contribuer
à  rendre les communications fiables et
économiques tout en fournissant une
bande passante suffisante.
La performance a toujours un
maillon faible : capacité de la CPU, mémoire,
performances de la base de
données, bande passante de la communication,
ou beaucoup d’autres facteurs
du système d’exploitation ou de
l’application. Une conception soignée
et un réglage efficace peuvent atténuer
les effets de bon nombre de ces facteurs.
Cela dit, les performances réelles
de votre système ne seront pas forcément
les mêmes que nos résultats
de laboratoire.
On peut aussi améliorer la performance
en intervenant sur WebSphere.
Songez à  régler les paramètres suivants
dans WebSphere Advanced Edition :

• Depuis la console Administration,
  dans le Web Container Service, notre
  expérience suggère de régler la
  Minimum thread size à  50 % du
  nombre d’utilisateurs par instance, la
  Maximum thread size à  100 % des
  utilisateurs par instance et dans le
  transport HTTP, et maximum keep
  alives à  100 % des utilisateurs par instance.
  Dans le Session Manager
  Service, changez le Maximum in-memory
  session count à  90 % des utilisateurs
  par instance (ou par clone si
  on utilise le cloning WebSphere).

• WebSphere présente une option
  dans l’Administrators Console pour
  définir la taille de pile initiale pour la
  JVM (Java Virtual Machine). Essayez
  d’utiliser une valeur de 4 Mo par utilisateur.
  (Si vous utilisez l’iSeries, ne
  définissez pas une valeur de pile
  maximale, l’iSeries JVM s’en chargera.)
  Si la pile est trop petite, elle
  peut causer une consommation de
  CPU excessive de la part du Java
  Garbage Collector. Si la pile est trop
  grande, elle peut causer un nombre
  excessif d’I/O disque à  cause des défauts
  de page.

• Le code J.D. Edwards OneWorld Java
  Application Server utilise JDBC
  comme un moyen d’accéder à  DB2.
  Dans la plupart des bases de données,
  il est possible de prédémarrer
  des jobs qui servent ces requêtes
  JDBC DB2 via une commande
  iSeries. Nous avons constaté que le
  nombre optimal de jobs était égal à 
  40 % des utilisateurs simultanés
  parce que l’implémentation iSeries
  utilise le pooling de connexion
  WebSphere. Voici un exemple de
  commande qui change le nombre de
  jobs à  1 000 :

  CHGPJE SBSD(QUSRWRK) PGM(QZDASOINIT)
  INLJOBS(1000)

  Ces valeurs sont proposées uniquement
  comme des points de départ
  et, avant de les intégrer dans un environnement
  de production donné, il
  faut s’assurer de leur adéquation.