2.2.2 Architecture d'un serveur Web

L'architecture d'un serveur Web travaillant avec une politique de concurrence thread-per-request est décrite dans la Figure 8. Un thread principal reçoit les connexions arrivant sur le port TCP 80 et pour chaque nouvelle connexion il crée un nouveau thread. Ce dernier sert les requêtes qui arrivent sur la connexion (une seule requête pour HTTP/1.0 ou plusieurs requêtes dans le cas de HTTP/1.1).

message URL fig8.gif
Figure 8 L'architecture d'un serveur Web (thread-per-request)

Le diagramme des états pour un fil d'exécution (thread) qui répond aux requêtes provenant d'un client HTTP est décrit dans la Figure 9. Le thread est dans un état Ready où il attend des requêtes de la part du client. Dès qu'il reçoit une requête, il passe dans l'état Parse. Si la commande n'est pas valide, le thread enregistre l'erreur dans un fichier texte avec un format spécial (fichier log) et il s'arrête (si HTTP/1.0) ou revient dans l'état Ready (si HTTP/1.1). Si la requête est valide, elle sera traitée dans l'état Process, où le serveur construit et envoie la réponse.

message URL fig9.gif
Figure 9 Un diagramme d'états schématique pour un thread répondant à un client HTTP

Ce diagramme des états est important afin de déterminer les facteurs qui influencent les performances d'un serveur Web. D'après [almeida96], l'état Log apparaît pour 15% du temps d'exécution d'un serveur Web chargé. Le temps passé dans l'état Parse dépend principalement de la puissance de calcul du serveur, et généralement il est négligeable pour des requêtes statiques (pages Web, fichiers). Le majeure partie du temps est passé dans l'état Process, où les performances du système de stockage et du réseau déterminent le temps de réponse à une requête statique.