Comment puis-je déterminer très précisément ce qui cause la lenteur de mon serveur web ?

Eh bien, mon premier réflexe, si je croyais que le ralentissement était dû à un trafic excessif sur une URL ou un fichier, serait de vérifier les journaux du serveur Web ou toute analyse que vous pourriez avoir. Cela vous indiquera le type de trafic que vous rencontrez.

Voici quelques choses que vous pouvez vérifier si vous supposez que c'est un problème lié à la bande passante:

• Comme mentionné dans une autre réponse, vérifiez les journaux d'accès/erreur pour obtenir un historique de tous les clients créant plus de trafic que d'habitude. Si c'est un petit site, vous pouvez peut-être regarder manuellement les journaux. Sinon, envisagez d'utiliser un outil d'analyse/visualisation de journal pour ce type de journal.
• Si votre fournisseur de serveur dispose d'un graphique/affichage de l'utilisation du réseau pour votre serveur, vous pouvez l'utiliser comme guide approximatif pour voir s'il y a des pics d'utilisation.
• Vous pouvez utiliser ''ifconfig -a'' pour consulter l'utilisation brute des interfaces réseau de votre serveur.
• Vous pouvez utiliser ''netstat -an'' pour lister toutes les connexions actuelles.
• Utilisez le module de statut d'Apache/lighttpd (ou un module similaire pour votre application serveur) pour afficher la liste actuelle des clients connectés.
• Ne supposez pas que le problème est nécessairement lié à la bande passante, surtout si rien d'anormal ne ressort des journaux/statistiques.
• Envisagez d'installer une sorte d'application de surveillance au cas où vous auriez du mal à trouver le problème lorsqu'il se produit.

Les scripts suivants que j'utilise me donnent une idée de base de l'état des connexions sur un serveur en utilisant netstat. Le premier affiche simplement le nombre de connexions en fonction du type de connexion:

  #!/bin/sh
  # Affiche le nombre de connexions sur un serveur
  #
  echo -n $"Établies: "
  netstat -an | grep ESTABLISHED | wc -l

  echo -n $"   Syn Recv: "
  netstat -an | grep SYN | wc -l

  echo -n $"       Attente: "
  netstat -an | grep WAIT | wc -l

  echo -n $"     Écoute: "
  netstat -an | grep LISTEN | wc -l

  echo -n $"      Total: "
  netstat -an | wc -l

Il est normal d'avoir un grand nombre de connexions dans l'état d'Attente (du moins d'après ce que j'ai observé). Un grand nombre de connexions SYN peut être lié à une attaque DOS par inondation SYN.

Le script suivant compte le nombre de connexions établies par adresse IP et est utile pour voir s'il y a une adresse IP particulière qui se comporte mal.

#!/bin/sh
# Compte le nombre de connexions par adresse IP

netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Si votre serveur est soumis à une lourde charge et que vous avez des milliers de connexions, ce script peut prendre un peu de temps pour s'exécuter (~1 minute dans le pire cas que j'ai vu).

Remarquez que selon votre application, des entrées multiples par IP ne sont pas nécessairement mauvaises. Par exemple, dans mon cas, 10 à 20 entrées par IP sont normales, mais au-delà de ce nombre, c'est suspect. J'ai vu des adresses IP 'mauvaises' demander le même document/fichier des centaines de fois ou parcourir tous les fichiers du site et les télécharger. Le dernier script facilite relativement la repérage de ces adresses IP que vous pouvez ensuite utiliser pour consulter vos journaux pour plus de détails si nécessaire.

Il n'existe pas de méthode générale pour déboguer les performances médiocres d'un serveur web, mais il existe quelques outils qui pourraient vous être utiles. Je suppose que vous utilisez une pile http sous linux.

1. Journalisez le temps nécessaire pour traiter chaque requête. (dans apache vous pouvez définir LogFormat à: LogFormat %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D** combined puis essayez de déterminer les GETs ou POSTs les plus longs à partir du fichier journal.
2. L'analyse quasi temps réel du fichier journal peut être réalisée en utilisant la commande apachetop (pour les fichiers journaux au format apache, pas nécessairement générés par apache) apachetop -f /var/log/apache2/access.log vous donnera un bon aperçu des requêtes en attente
3. Sur le côté client, vous pouvez utiliser certains outils de développement web pour déterminer quels éléments du site le plus fréquenté se chargent trop lentement. Je recommande firebug http://getfirebug.com/ un plugin pour firefox.
4. Vérifiez les performances du disque du serveur. En utilisant atop http://www.atoptool.nl/ vous pouvez rapidement déterminer quels disques sont occupés à 100%. Cela peut être un problème surtout lorsque vous utilisez un moteur de base de données (mysql ou pgsql) sur les mêmes hôtes et que vous rencontrez un trafic élevé.
5. Les gros fichiers statiques ne devraient pas être servis par apache. La meilleure façon de faire fonctionner apache correctement est de servir tout ce que vous pouvez, par d'autres serveurs légers - (c'est-à-dire nginx, lighthttpd...). Essayez de trouver le plus gros fichier servi par votre serveur web et servez-les via nginx.
6. Vérifiez également les statistiques d'utilisation de la bande passante. Si vous atteignez les limites de votre réseau, les pages se chargeront beaucoup plus lentement et le serveur sera surchargé.

Chaque administrateur système qui a combattu de tels problèmes que les vôtres, pourrait probablement énumérer de nombreux autres conseils rapides, mais le fait est que toutes ces règles dépendent beaucoup de l'environnement (matériel, système d'exploitation, serveur web, application, base de données) et ne peuvent être apprises que par l'expérience. Souvent assez douloureux.

Considérez surveiller le système avec un outil comme sar ou Munin. Cela vous donnera des informations sur les composants les plus occupés. J'aime Munin pour ses rapports graphiques, ainsi que sa capacité à définir des alertes. sar fournit de bons détails sur l'activité du disque et du swap.

Inclure le temps de service dans le journal Apache est utile. Je change généralement le champ de nom de journal distant (ident) (%l) avec le temps nécessaire pour traiter la demande (%T) dans le format de journal étendu.