Le volume de trafic que votre serveur Web traite est probablement le meilleur indicateur de son intensité de travail. Bien que l'on puisse définir le trafic de différentes manières, je le définis comme le nombre de requêtes par seconde que le serveur Web traite - pas le nombre de connexions
Trafic du serveur Web
au serveur
Web. Comme cette définition ne
fait pas l’unanimité, je veux prendre un
instant pour expliquer pourquoi le
nombre de requêtes par seconde est
un meilleur indicateur de la charge du
serveur.
Quand un utilisateur tape dans son
navigateur un URL dans un emplacement
sur votre serveur Web, le navigateur
ouvre une connexion avec le serveur
Web et demande la page Web.
Quand le navigateur reçoit la page, il
peut fermer la connexion, la réutiliser,
ouvrir plusieurs autres connexions
pour demander JavaScript, des images,
et des CSS (Cascading Style Sheets) à
partir du serveur Web. Une fois que le
navigateur a rendu complètement la
page, la connexion peut rester ouverte,
mais le serveur Web n’a rien à
faire pendant que l’utilisateur lit la
page. La connexion ouverte ne demande
pas que le serveur Web travaille
; le serveur ne travaille que pendant
qu’il traite la requête. En fait, les
connexions TCP ne sont pas persistantes
et le serveur n’a pas besoin de
travailler pour maintenir une
connexion inactive – il stocke simplement
certaines informations de
connexion dans la RAM.
C’est pourquoi je recommande de
surveiller le compteur Get Request/sec
de l’objet Web Service. C’est un
meilleur indicateur de trafic que le
compteur Current Connections de
l’objet. Get Request/sec indique combien
de requêtes GET le serveur traite
à une seconde particulière. Si votre site
a beaucoup de postes, vous pouvez
aussi examiner le compteur Post
Requests/sec. Le champ Last est intéressant
mais, pour évaluer le trafic,
vous devriez regarder le champ
Average. A titre de référence, la plupart
des serveurs Web ne travaillent réellement
que quand ils atteignent une
moyenne de plus de 50 requêtes par
seconde. Si votre serveur Web peut
traiter ce nombre de requêtes, vous
devez surveiller les goulets d’étranglement
de threading ou de programme.
Des serveurs bien réglés peuvent traiter
plus de 250 requêtes par seconde
en moyenne. Un trafic continu à 50 requêtes
par seconde correspond à 4,32
millions de requêtes, ou hits, par jour.
Vous pouvez aussi surveiller le
nombre d’octets que le serveur Web
envoie et reçoit. Une requête GET a généralement
de 100 octets à 500 octets ;
une requête POST peut être bien plus
grosse. Utilisez les compteurs Bytes
Received/Sec et Bytes Sent/Sec de l’objet
Web Service et le champ Average.
Sachez que le débit maximum d’un
LAN 10Base-T est d’environ 9 MBps ou
1,125 MBps ; ne vous attendez pas à ce
que votre serveur Web dépasse les limites
du réseau.
Un autre compteur d’objet Web
Service utile est Service Uptime, que
vous pouvez utiliser avec une instance
de site Web que vous spécifiez, pour
indiquer le nombre de secondes pendant
lesquelles un site Web a fonctionné.
Vous pouvez utiliser le compteur
Service Uptime pour vérifier si
IISreset (qui est livré avec Internet
Information Service – IIS – 5.1 et IIS
5.0) ou un autre utilitaire de surveillance
a redémarré le site Web au
milieu de la nuit.
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.