Composants de performances de HTTP Server

conception qui travaillent à  l’unisson.
La figure 2 montre une partie des
nombreux composants qui contribuent
à  la performance globale d’une
application Web. On voit tout de suite
que FRCA est une tâche qui s’exécute
complètement au-dessous de MI
(Machine Interface) d’OS/400. Cette
disposition permet à  FRCA d’être performant
comme tâche routeur SLIC
(System Licensed Internal Code), ce
qui évite le coût élevé du passage à  un
thread serveur au niveau utilisateur tel
que le HTTP Server. FRCA peut servir
le contenu Web soit par l’intermédiaire
d’un cache local pour le contenu statique,
soit sous la forme d’un cache reverse-
proxy pour le contenu dynamique.
Il en résulte un cache
« conscient de HTTP » extrêmement
puissant fonctionnant dans SLIC.
Le NFC (Network File Cache) est
un autre nouveau composant de
l’OS/400 V5R2. Il offre le moyen de
stocker et d’extraire efficacement des
fichiers cachés et des fonctions comme
un système de mini-fichiers (par
exemple, ouvrir, lire, écrire, fermer)
pour des tâches SLIC.
Au-dessus du MI se trouve le HTTP
Server. On y trouve des options de
configuration permettant de contrôler
diverses valeurs de performances, globales
et spécifiques. Pour plus de détails,
voir le Redbook HTTP Server (powered
by Apache) : An Integrated
Solution for IBM eServer iSeries
Servers (SG24-6716). Le HTTP Server
peut aussi maintenir un cache local qui
est configuré et maintenu séparément
du NFC utilisé par FRCA.
Le HTTP Server peut servir des fichiers
statiques directement à  partir de
l’IFS. Mais, si ces fichiers sont présents
dans le cache local ou le NFC, il est clair
que cela réduira le temps et l’effort nécessaires
pour extraire le contenu du
fichier.
Un serveur HTTP n’est en soi rien
d’autre qu’un serveur de fichiers d’un
genre un peu spécial. Mais, dans un ebusiness,
il est le point de passage de
toutes les transactions Web. Les utilisateurs
demandent souvent un contenu
dynamique qui est servi directement à 
partir de l’application Web. Pour éviter
une consommation coûteuse de CPU
et de mémoire, ces applications Web
maintiennent souvent leur propre
cache d’application.
Le TCM (Triggered Cache Manager)
n’est pas un cache mais, comme le
nom l’indique, un gestionnaire de
cache. Son rôle est d’attendre que des
déclencheurs programmés (résultant
très probablement d’une mise à  jour
dans votre base de données LOB
(Large Object)) qui indiquent que le
moment est venu de mettre à  jour une
ou plusieurs pages Web. TCM régénère
ces pages Web de façon proactive et les
place dans l’IFS iSeries (que l’on peut
considérer comme un cache local pour
TCM) pour être servies comme un fichier
statique local. Jusqu’à  ce que les
données brutes de la base de données
LOB changent à  nouveau, le serveur
iSeries HTTP sert un contenu « dynamique
» à  des vitesses de fichier statiques.
Le point important est que TCM
met à  jour le contenu de l’IFS uniquement
si et quand les données brutes
ont été mises à  jour dans la base de
données LOB.
FRCA, nous le verrons, peut aussi
« cacher » un contenu dynamique que
l’on peut faire expirer au moyen d’un
timer. Bien que TCM semble le
meilleur choix pour cette fonction, il
n’est pas exempt de programmation.
En revanche, FRCA se contente d’une
simple configuration.
Les directives FRCA sont simplement
imbriquées dans le fichier de
configuration HTTP Server (httpd.
conf) qui permet à  votre serveur HTTP d’utiliser le cache FRCA. Vous pouvez
valider FRCA pour chaque port
d’écoute dans la configuration serveur.
Cela vous permet de choisir entre utiliser
ou non le cache FRCA sur chaque
Listen sur un spécifique.
Vous pouvez cacher un contenu
statique en indiquant un
nom de fichier ou un
groupe de noms de fichiers
en utilisant des jokers
comme l’astérisque (*). Le
chargement du cache a lieu
pendant le démarrage de
HTTP Server ou à  l’exécution,
selon votre configuration.
Voici un exemple

FRCACacheLocalFileStartup
/ITSO/ITSOco/Downloads/*.html

Le contenu dynamique,
comme le résultat d’une requête
HTTP adressée à  un
« Content Server », peut
être « caché » par la spécification
d’un URI (Universal
Resource Indicator) (c’està –
dire, la portion de chemin d’un URL)
pour identifier la requête qui est ensuite
associée à  un URL entièrement
qualifié. C’est ce qu’on appelle le reverse-
proxy cache et il permet d’accéder
à  un serveur HTTP soit sur le
même iSeries, soit n’importe où sur
l’intranet ou l’Internet, pour fournir un
contenu dynamique automatiquement
caché dans le NFC. Un timer détermine
quand les éléments cachés sont
anciens. Voici un exemple d’utilisation

FRCAProxyPass /cgi-bin/
http://as21.domain.com:9999/cgi-bin/
FRCAProxyCacheRefreshInterval /cgi-bin/ 180

A ce stade, il faut bien comprendre
que FRCA regroupe deux mécanismes
de cache différents enveloppés dans
un package. FRCA est à  la fois

• un cache local pour des fichiers IFS
  généralement statiques par nature

• un cache reverse-proxy (nous y reviendrons
  plus loin) pour un
  contenu qui a été généré par un serveur
  de contenu dynamique qui, soit
  fonctionne sur votre iSeries local,
  soit est connecté via un réseau
  TCP/IP