Considérations concernant le serveur Web
Même si le serveur Web relève d'une technologie avancée, il peut toujours être optimisé pour améliorer les performances, en particulier sur les sites Web de grande taille. Cette section présente les considérations courantes en matière de performances pour tous les serveurs Web, quel que soit le système d'exploitation.
Programmes d'écoute d'unités d'exécution ou de processus
Si le serveur Web reçoit uniquement des demandes dynamiques pour le serveur d'applications, le nombre de programmes d'écoute HTTP doit être légèrement supérieur au nombre d'unités d'exécution défini dans le serveur d'applications. Dans HCL Commerce, dans le cadre duquel le contenu statique (c'est-à-dire les fichiers image tels que les fichiers GIF et JPG) est distribué par le serveur Web et non par le servlet de service de fichiers, il est nécessaire de configurer plus de programmes d'écoute pour obtenir des performances optimales.
- ThreadLimit
- ServerLimit
- StartServers
- MaxClients
- MinSpareThreads
- MaxSpareThreads
- ThreadsPerChild
- MaxRequestsPerChild
Distribution d'images
Les images statiques sont stockées sur le serveur Web et distribuées à partir de ce serveur au fur et à mesure de l'accès aux pages associées. Pour les implémentations comportant un grand nombre d'images, il est recommandé de répartir ces images sur plusieurs répertoires afin de réduire le temps de balayage du système d'exploitation durant la distribution des images par le serveur Web. Il est conseillé de ne pas placer plus de 50 000 images dans un répertoire d'images.
Consignation
Les serveurs Web autorisent différents niveaux de consignation pour différents jeux d'informations. Même si cette consignation est utile pour diagnostiquer les incidents, elle a un impact important sur les performances sur les sites Web portant sur de gros volumes. Pour améliorer les performances, conservez un seul journal et limitez-le aux erreurs de serveur.
Dans IBM HTTP, le paramètre LogFormat contrôle la quantité d'informations consignée dans les fichiers journaux. Pour plus d'informations sur la procédure de modification de ces paramètres, voir IBM HTTP Server Performance Tuning.
Signal de présence
Dans le cadre du protocole HTTP, chaque demande crée une nouvelle connexion socket au serveur et envoie une demande. Lorsque le serveur répond, il crée une autre connexion socket pour répondre au client. Ce concept est simple à comprendre, mais lent du point de vue des performances. Il serait intéressant de pouvoir utiliser la même connexion pour la requête et la réponse. C'est pour cela que la fonction de signal de présence est utilisée : elle permet au serveur de gérer de longues connexions. La nombre maximal de requêtes qu'un navigateur peut effectuer sur une connexion longue et la durée maximale d'activité de la connexion sont des paramètres configurables.
La fonction de signal de présence est activée par défaut sur la plupart des serveurs Web. La valeur affectée aux paramètres de signal de présence dépend des caractéristiques de trafic du site Web. Le nombre maximal de connexions en mode signal de présence et les valeurs de délai d'attente associées à ces connexions doivent être optimisés de telle manière qu'il y ait un équilibre entre les performances (éviter la création de connexions socket) et les ressources (la connexion en mode signal de présence ne peut pas être réutilisée pour une autre connexion avant l'expiration du délai).
- KeepAlive
- MaxKeepAliveRequests
- KeepAliveTimeout