Triturons TCP/IP

IBM par défaut, on peut améliorer considérablement les performances du réseau
et fournir des temps de réponse plus rapides aux utilisateurs tout en allégeant
la charge de la CPU de l’AS/400.

En procédant à  quelques ajustements mineurs mais fondamentaux on peut
améliorer considérablement les performances du réseau

Si on utilise la V4R4 avec un adaptateur Ethernet, on peut modifier la description
de ligne Ethernet (LIND) pour ne supporter que TCP/IP, via le paramètre TCPONLY
(figure 3). Dans ce cas, l’IOP Ethernet, à  la prochaine réinitialisation, chargera
une version optimisée TCP/IP de son microcode et transfèrera un certain nombre
de fonctions TCP (calcul et vérification des totaux de contrôle, par exemple)
du processeur principal AS/400 sur l’IOP. Mais rappelons que, après ce réglage,
plus question d’utiliser SNA ou IPX avec cette interface. Par conséquent, avant
de procéder à  de telles modifications, il faut s’assurer qu’aucune application
ne dépend de ces protocoles.

Quelle que soit la release de l’OS/400, le fait d’augmenter la quantité de mémoire
allouée au traitement des paquets TCP/IP améliore les performances. La valeur
par défaut d’IBM pour les paramètres de taille des buffers d’envoi et de réception
TCP/IP de la commande CHGTCPA (Change TCP/IP Attributes) (figure 4) n’est que

de 8192 octets. Avant la V4R4, la valeur utile maximum était de 65536 octets par
buffer et il faut toujours modifier pour obtenir ce nombre. La V4R4 est capable
de tirer parti d’un maximum de 8 Mo (8.388.608 octets) pour traiter de gros volumes
de transactions. Selon la quantité de mémoire disponible, un plus grand nombre
d’octets peut augmenter le nombre de transactions simultanées que l’AS/400 peut
traiter. Il faudrait allouer un million (1.000.000) d’octets à  chaque buffer si
possible, et plus si la mémoire disponible le permet.

Le dernier paramètre de communication que l’on peut modifier pour améliorer les
performances TCP/IP est la taille de la MTU (Maximum Transmission Unit). Cette
valeur définit la taille maximale d’un paquet TCP/IP : 576 octets par défaut.
C’est bien trop petit pour Ethernet, qui peut accepter jusqu’à  1496 octets par
paquet. La valeur par défaut fait que l’OS/400 transmet et reçoit trois fois plus
de paquets que nécessaire, augmentant considérablement la charge de la CPU et
de l’IOP et utilisant inefficacement la bande passante disponible par suite d’en-têtes
de paquets redondants.

Pour modifier la valeur de MTU, dans le menu Configure TCP/IP (GO CFGTCP), choisir
 » Work with TCP/IP Routes  » pour sélectionner les routes pour lesquelles on veut
modifier la taille de la MTU. Généralement, on n’en choisira qu’une, la route
par défaut (*DFTROUTE), mais si l’AS/400 possède des routes allant vers des réseaux
autres qu’Internet, il faut aussi songer à  les modifier. Le fait de définir l’option
Change sur une route amène l’invite de commande CHGTCPRTE (Change TCP/IP Route)
(figure 6). Changer le paramètre en « Interface » *IFC pour ordonner à  TCP/IP d’utiliser
la plus forte valeur possible pour l’interface en service (Ethernet, Token Ring,
par exemple). Les descriptions de ligne par défaut fournies par IBM pour Ethernet
contiennent la taille MTU correcte de 1492 octets.

Outre la modification des paramètres de communication génériques, on peut aussi
améliorer les performances en modifiant quelque peu la configuration du serveur
HTTP. Les deux modifications les plus courantes consistent à  désactiver le lookup
DNS (Domain Name Service) et à  activer la mise en mémoire cache des objets fréquemment
demandés. En fouillant dans la documentation du fournisseur, on trouvera peut-être
d’autres astuces pour améliorer les performances du serveur.

Le lookup DNS est l’opération consistant à  examiner le nom de l’adresse IP de
chaque visiteur du site, afin d’enregistrer le nom dans le fichier journal du
serveur HTTP. S’il est vrai que cette technique facilite la lecture manuelle du
fichier journal, elle a pour inconvénient de ralentir parfois considérablement
le fonctionnement du site Web. Tout simplement parce que la page initiale d’un
utilisateur donné ne s’affiche qu’une fois la résolution DNS terminée – une opération
qui peut durer plusieurs secondes. Si aucun nom n’est associé à  l’adresse IP du
visiteur, celui-ci doit attendre le time out de DNS (en principe une minute ou
plus) avant d’obtenir le contenu du Web. Pis encore, comme la plupart des serveurs
DNS ne mettent pas en mémoire cache des réponses  » négatives  » (c’est-à -dire,
non trouvées), les utilisateurs devront subir cette attente pour chaque objet
délivré par le serveur Web, rendant du même coup l’accès pratiquement impossible.

Le lookup DNS en temps réel n’est pas vraiment nécessaire parce que la grande
majorité des outils d’analyse de journaux effectueront cette opération en mode
batch, bien plus efficace. On améliorera grandement le temps de réponse en désactivant
le lookup DNS. La figure 7 montre comment procéder avec le serveur HTTP d’IBM.

La mise en mémoire cache des objets Web soumis à  de fréquents accès, accélère
le temps de réponse en éliminant des accès disque. Pour la plupart des serveurs,

cette fonction est activée par défaut, mais la taille du cache est initialement
réglée sur une taille plus petite (quelques centaines de Ko au plus). S’il y a
de la mémoire disponible, l’augmentation de la taille de la mémoire cache à  plusieurs
Mo peut réduire de plus de 50 % le nombre de lectures disque si une grande partie
du contenu est servie de manière répétitive. Au-delà  de la mise en mémoire cache,
on peut aussi envisager un cache externe (décrit plus loin) pour améliorer encore
davantage les performances.