Déplacement des charges de travail

d’émulation
de terminal interactives, les jobs batch et d’autres serveurs TCP/IP (FTP, DNS,
SMTP par exemple) vers d’autres serveurs, de préférence sur d’autres segments
Ethernet.

On évitera d’utiliser certains services, et tout particulièrement AnyNet, NetServer
(partage de fichier Windows) et Client Access, sur un serveur HTTP. Tous consomment
des quantités considérables de mémoire AS/400 et de temps CPU, même quand ils
ne traitent aucun trafic. Si on utilise ces services pour transférer des données
sur le serveur HTTP, il ne faut les activer que pendant le temps nécessaire au
transfert des fichiers HTML. Le fait de désactiver les serveurs quand ils ne sont
pas en service libère des ressources pour le traitement HTTP. Mieux encore, on
utilisera FTP pour transférer des fichiers HTML parce que le serveur FTP d’IBM
ne consomme des ressources que pendant l’exécution des transferts.

Et il n’est pas nécessaire de confier tous ces services à  un autre AS/400 : on
constatera que les incarnations Windows ou Unix de DNS, SMTP et des serveurs de
partage de fichiers sont plus faciles à  installer et à  maintenir que leurs homologues
AS/400.

Nous avons vu qu’une grande partie du contenu fourni par un serveur Web était
répétitive : tous les utilisateurs ont tendance à  télécharger la même home page,
les mêmes graphiques, et presque le même code HTML. Seul le contenu dynamique
diffère d’un utilisateur à  l’autre. Pour tirer parti du traitement transactionnel
de l’AS/400, on peut confier le contenu répétitif à  un serveur de proxy externe
(figure 8). Un cache externe se situera entre le serveur Web et les utilisateurs
à  distance, pour que toutes les requêtes adressées à  l’AS/400 passent d’abord
par le serveur de proxy, lequel les transmet ensuite, si nécessaire, à  l’AS/400.
Il fonctionne un peu comme la mémoire cache d’un serveur HTTP natif AS/400. La
première fois qu’une requête sur un objet particulier est reçue, le proxy la transmet
simplement au serveur AS/400. Quand le serveur répond en délivrant l’objet demandé,
il répond au serveur de cache, lequel retransmet l’objet au demandeur original.
En même temps, le serveur de cache conserve précieusement une copie de cet objet
(généralement sur disque), afin que le prochain demandeur
puisse être servi directement par le serveur de proxy au lieu de l’AS/400.

On peut créer son propre serveur de proxy en utilisant le logiciel de proxy d’un
ordinateur existant. Il existe des packages de cache en open-source, comme Apache
(http://www.apache.org) ou Squid (http://www.nlanr.net/Squid/). On peut aussi
acheter un dispositif de cache autonome. Apache et Squid fonctionnent tous deux
sur AS/400, et IBM prévoit de livrer des versions de ces serveurs dans les prochains
mois. La capacité du disque et de la mémoire cache sont les deux principaux critères
de choix d’un serveur de cache. Les deux capacités sont importantes : celle du
cache disque détermine la quantité maximale d’informations que l’on peut mettre
en cache, tandis que celle de la mémoire permet de garder sous la main les objets
les plus sollicités pour pouvoir les livrer rapidement sans accéder au disque.