Gérer la croissance de son serveur Web

Avant de savoir où l’on va, il faut savoir où l’on se trouve exactement. Comme
plusieurs facteurs influencent les performances du serveur Web, l’analyse des
performances a pour objectif de détecter les points de friction dans l’environnement
actuel. Même si l’on n’estime pas avoir un problème de performances, l’analyse
des performances de l’environnement serveur Web qui fonctionne de manière très
satisfaisante permet de créer une référence intéressante pour des comparaisons
à  venir. Un suivi continu des performances permet de détecter les changements
intervenant dans la demande, et d’y répondre avant que les performances ne se
dégradent.

L’AS/400 peut collaborer avec des serveurs Web de divers fournisseurs (comme nous
n’examinerons pas ici les offres de chaque fournisseur, renseignez-vous auprès
de l’éditeur du logiciel pour connaître les produits de tuning spécifiques). A
peu de choses près, tous ces produits effectuent un certain nombre de tâches similaires
:

· Servir des pages HTML statiques

· Délivrer de grands objets, comme des graphiques ou des applets Java

· Créer des threads d’exécution multiples pour des utilisateurs simultanés

· Exécuter des programmes HLL (High Level Language) via CGI (Common Gateway
Interface)

· Extraire et mettre à  jour des données via SQL

· Traiter des macros Net.Data

· Exécuter des servlets Java allant accéder aux objets de l’IFS (Integrated
File System)

· Crypter le trafic échangé avec des navigateurs actifs de type SSL (Secure
Sockets Layer)

Chacune de ces tâches consomme un précieux temps CPU, mais pas de manière égale.
La capacité de l’AS/400 à  répondre à  ces demandes dépend du mix de ces charges
de travail dans les applications. Tous les serveurs Web AS/400 utilisent plus
ou moins les mêmes fonctionnalités de l’OS/400 pour réaliser ces tâches. Ainsi,
les requêtes SQL sont traitées par DB2/400 et les servlets Java sont exécutés
par l’environnement d’exécution Java OS/400 natif.
C’est pourquoi IBM a publié des facteurs de performances (appelés temps CPU relatifs)
qui aident à  prévoir l’effet du changement de l’une quelconque de ces charges
dans l’environnement.

Le tableau de la figure 1 présente divers processus de serveurs Web et leurs temps
CPU relatifs. La tableau attribue un temps CPU relatif de 1 à  l’opération consistant
à  servir une page HTML statique directement depuis le disque pour la première
fois. Si l’on sert une page depuis la cache du serveur, on élimine tout accès
disque, et on va ainsi presque deux fois plus vite qu’avec la méthode sans cache,
et donc ce processus nécessite un temps CPU relatif de 0,6. Exécuter un programme
CGI est plus coûteux que de servir une page statique, et exécuter une macro Net.Data
l’est encore plus. L’opération la plus coûteuse en temps consiste à  exécuter une
macro Net.Data avec accès SQL. Ces relations permettent de conclure que Net.Data,
à  l’évidence très commode, est coûteux en temps CPU.
Par conséquent, en déplaçant la logique applicative vers Java, on peut sensiblement
améliorer les performances du serveur Web si les applications Web invoquent fréquemment
Net.Data. Pour des appels de programmes applicatifs extrêmement fréquents, un
programme CGI personnalisé écrit dans un HLM efficace, comme ILE
RPG ou ILE C, s’avèrera peut-être nécessaire pour obtenir de bonnes performances.
Les servlets Java peuvent aussi offrir des performances similaires, parfois
même meilleures que les programmes CGI personnalisés. Il est bien plus simple
de faire de tels choix au stade de la conception qu’une fois l’application déployée.

Il est bien plus simple de faire de tels choix au stade
de la conception qu’une fois l’application déployée

La troisième colonne de la table, ratio de cryptage, indique la pénalité en termes
de performances supplémentaires, imposée par le cryptage SSL (Secure Sockets Layer).
On peut facilement contrôler ce facteur par de simples modifications de l’application
au niveau HTML. Le ratio de cryptage représente le  » facteur multiplicateur ralentisseur
 » à  appliquer aux temps de CPU relatifs pour les transactions cryptées. Ainsi,
le temps CPU net pour une servlet cryptée est de 4,06 (2,9 x 1,4). Quand la sécurité
est importante, il est tentant de crypter tout simplement tout le trafic Web via
SSL, pour ne pas risquer le piratage d’informations sensibles. Mais on risque
alors de diviser les performances par trois. La forme URL  » https://  » invoque
le cryptage SSL ; en n’utilisant cette forme d’URL qu’en cas de besoin (par exemple
lors du traitement de la partie paiement d’une transaction de e-commerce) on peut
beaucoup soulager la CPU.
Si on dimensionne un AS/400 en vue de son utilisation comme serveur Web, il peut
être intéressant d’utiliser le Workload Estimator for AS/400 d’IBM (http://as400service.ibm.com/estimator).
Cet outil permet d’indiquer, en termes très généraux, les genres de charges (comme
l’utilisation de Java) le nombre d’utilisateurs et le débit transactionnel que
l’on attend de l’AS/400.

Après cela, il génère une configuration modèle qu’IBM estime adaptée en la circonstance.
Comme les estimations d’IBM sont plutôt généreuses, on n’est pas obligé de suivre
aveuglément les recommandations de cet outil. Une vérification supplémentaire
consiste à  écrire l’application de manière à  éviter les tâches coûteuses à  chaque
fois que c’est possible, puis à  faire des mesures de performances réelles sur
un vrai AS/400 pour déterminer la taille finale du serveur.

Une fois le serveur Web en action, il est difficile de mesurer ces différents
facteurs de charge en utilisant les outils de mesure de performances AS/400 traditionnels.
Cependant, tous les serveurs Web AS/400 permettent de journaliser le travail réel
effectué par le serveur. Ce journal contient les informations les plus importantes
sur les performances HTTP (Hypertext Transfer Protocol) du serveur. Le format
de journalisation HTTP est standardisé sur Internet, et l’immense majorité des
serveurs Web respectent le standard. Ce format de journal enregistre la date et
l’heure de chaque transfert HTTP, la voie et la taille de l’objet transféré et,
enfin, l’identité de l’utilisateur demandant le transfert.

Ce niveau très poussé de détail se traduit par des journaux volumineux, difficiles
à  interpréter sans assistance. Heureusement, il existe de nombreux outils d’analyse
capables de tirer des statistiques pertinentes et utiles des journaux HTTP. L’un
de ces outils pour l’AS/400 est le composant WebSphere Site Analysis d’IBM, un
élément de WebSphere Application Server, dont l’édition standard est gratuite
ur AS/400. Fonctionnant sous Windows, WebSphere Site Analysis extrait automatiquement
les journaux des serveurs HTTP de l’AS/400, et génère un ensemble de rapports
prédéfinis (graphiques à  l’appui), que chacun peut adapter à  ses propres besoins.

Et, comme le Site Analyzer présente les charges du trafic dans le temps, on peut
déceler les tendances (figure 1) et connaître les pics de demande sur le serveur.
Il fournit également un récapitulatif des transactions HTTP par objet Web, fréquence
et taille (figure 2), permettant d’identifier les objets fortement sollicités,
mûrs pour l’optimisation. D’autres rapports analysent le trafic par utilisateur,
par session, et par lieu géographique. Une fonction de contenu dynamique suit
les paramètres transmis aux servlets Java et aux JSP (Java Server Pages). L’outil
fonctionne de manière périodique (chaque nuit, par exemple), utilisant une session
FTP planifiée pour extraire le journal HTTP AS/400 et le traiter. Comme la sortie
est également au format HTTP, il est facile de distribuer rapports et graphiques.

Le serveur Web que l’on utilise possède peut-être ses propres outils d’analyse
de journaux, ou on peut acheter des outils tiers, capables de traiter les journaux
HTTP standards. En tout cas, il est important de ne pas remettre à  plus tard l’analyse
périodique des journaux Web. L’établissement d’une référence en matière de performances
et le suivi des tendances sont le point de départ de toutes les autres techniques
d’amélioration des performances.