Apache Bench - Configuration de l'environnement

Dans ce chapitre, nous vous expliquerons comment configurer votre environnement pour Apache Bench sur votre VPS.

Exigence du système

  • Memory - 128 Mo

  • Disk Space - Aucune exigence minimale

  • Operating System - Aucune exigence minimale

Installation d'Apache Bench

Apache Bench est une application autonome et n'a aucune dépendance sur l'installation du serveur Web Apache. Voici un processus en deux étapes pour installer Apache Bench.

Step 1 - Mettre à jour la base de données des packages.

# apt-get update

Veuillez noter que le symbole # avant une commande de terminal signifie que l'utilisateur root émet cette commande.

Step 2 - Installez le package apache2 utils pour accéder à Apache Bench.

# apt-get install apache2-utils

Apache Bench est maintenant installé. Si vous souhaitez tester une application Web hébergée sur le même VPS, il suffit d'installer uniquement le serveur Web Apache -

# apt-get install apache2

En tant qu'utilitaire Apache, Apache Bench est automatiquement installé lors de l'installation du serveur Web Apache.

Vérification de l'installation d'Apache Bench

Voyons maintenant comment vérifier l'installation d'Apache Bench. Le code suivant aidera à vérifier l'installation -

# ab -V

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Lorsque vous voyez la sortie du terminal ci-dessus, cela signifie que vous avez correctement installé Apache Bench.

Création d'un utilisateur Sudo privilégié

Du point de vue de la sécurité, il est considéré comme une bonne pratique pour l'administrateur système de créer un utilisateur sudo au lieu de travailler en tant que root. Nous allons créer un utilisateur de test, nommé test, dans le but -

# useradd -m -d /home/test -g sudo test

Définissons le mot de passe du nouvel utilisateur -

# passwd test

Le système demandera un nouveau mot de passe pour le test utilisateur. Vous pouvez entrer un mot de passe simple car nous ne faisons que tester et non déployer sur le serveur de production. Habituellement, la commande sudo vous invite à fournir le mot de passe de l'utilisateur sudo; il est recommandé de ne pas utiliser de mot de passe compliqué car le processus devient fastidieux.

Output

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

Test du site Web Apache.org

Dans cette section, nous testerons le site Web Apache.org. Passons d'abord au test utilisateur sudo -

# su test

Pour commencer, nous allons tester le site Web de l'organisation Apache, https://www.apache.org/. Nous allons d'abord exécuter la commande, puis comprendre la sortie -

$ ab -n 100 -c 10 https://www.apache.org/

Ici -nest le nombre de requêtes à effectuer pour la session de benchmarking. Par défaut, il suffit d'exécuter une seule demande, ce qui conduit généralement à des résultats d'analyse comparative non représentatifs.

Et -cest la concurrence et indique le nombre de demandes multiples à effectuer à la fois. La valeur par défaut est une demande à la fois.

Ainsi, dans ce test, Apache Bench effectuera 100 requêtes avec concurrence de 10 au serveur d'organisation Apache.

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

Après avoir exécuté notre premier test, il sera facile de reconnaître le modèle d'utilisation de cette commande qui est la suivante -

# ab [options .....]  URL

où,

  • ab - Commande Apache Bench

  • options - drapeaux pour une tâche particulière que nous voulons effectuer

  • URL - URL du chemin que nous voulons tester

Comprendre les valeurs de sortie

Nous devons comprendre les différentes métriques pour comprendre les différentes valeurs de sortie renvoyées par ab. Voici la liste -

  • Server Software - C'est le nom du serveur Web renvoyé dans l'en-tête HTTP du premier retour réussi.

  • Server Hostname - C'est le DNS ou l'adresse IP donnée sur la ligne de commande.

  • Server Port- C'est le port auquel ab se connecte. Si aucun port n'est indiqué sur la ligne de commande, ce sera par défaut 80 pour http et 443 pour https.

  • SSL/TLS Protocol- C'est le paramètre de protocole négocié entre le client et le serveur. Cela ne sera imprimé que si SSL est utilisé.

  • Document Path - Il s'agit de l'URI de la demande analysée à partir de la chaîne de ligne de commande.

  • Document Length- Il s'agit de la taille en octets du premier document renvoyé avec succès. Si la longueur du document change pendant le test, la réponse est considérée comme une erreur.

  • Concurrency Level - Il s'agit du nombre de clients simultanés (équivalent aux navigateurs Web) utilisés pendant le test.

  • Time Taken for Tests - Il s'agit du temps écoulé entre le moment où la première connexion socket est créée et le moment où la dernière réponse est reçue.

  • Complete Requests - Le nombre de réponses réussies reçues.

  • Failed Requests- Le nombre de demandes considérées comme un échec. Si le nombre est supérieur à zéro, une autre ligne sera imprimée indiquant le nombre de demandes qui ont échoué en raison de la connexion, de la lecture, d'une longueur de contenu incorrecte ou d'exceptions.

  • Total Transferred- Le nombre total d'octets reçus du serveur. Ce nombre est essentiellement le nombre d'octets envoyés sur le câble.

  • HTML Transferred- Le nombre total d'octets de document reçus du serveur. Ce nombre exclut les octets reçus dans les en-têtes HTTP

  • Requests per second- C'est le nombre de requêtes par seconde. Cette valeur est le résultat de la division du nombre de demandes par le temps total nécessaire.

  • Time per request- Le temps moyen passé par demande. La première valeur est calculée avec la formule simultanéité * timeaken * 1000 / done tandis que la seconde valeur est calculée avec la formule timeaken * 1000 / done

  • Transfer rate - Le taux de transfert tel que calculé par la formule totalread / 1024 / timeaken.

Analyse rapide de la sortie du test de charge

Après avoir appris les en-têtes des valeurs de sortie de la commande ab, essayons d'analyser et de comprendre les valeurs de sortie pour notre test initial -

  • L'organisation Apache utilise son propre logiciel de serveur Web - Apache (version 2.4.7)

  • Le serveur écoute sur le port 443 à cause de https. Si cela avait été http, cela aurait été 80 (par défaut).

  • Le total des données transférées est de 58769 octets pour 100 requêtes.

  • Test terminé en 1,004 secondes. Aucune demande n'a échoué.

  • Requêtes par seconde - 99,56. Ceci est considéré comme un assez bon nombre.

  • Temps par requête - 100,444 ms (pour 10 requêtes simultanées). Donc, pour toutes les demandes, il est de 100,444 ms / 10 = 10,044 ms.

  • Taux de transfert - 1338,39 [Ko / s] reçus.

  • Dans les statistiques de temps de connexion, vous pouvez observer que de nombreuses requêtes ont dû attendre quelques secondes. Cela peut être dû au fait que le serveur Web Apache met les demandes en file d'attente.

Dans notre premier test, nous avions testé une application (ie, www.apache.org) hébergée sur un serveur différent. Dans la dernière partie du didacticiel, nous testerons nos exemples d'applications Web hébergées sur le même serveur à partir duquel nous exécuterons les tests ab. C'est pour faciliter l'apprentissage et la démonstration. Idéalement, le nœud hôte et le nœud de test doivent être différents pour une mesure précise.

Pour mieux apprendre ab, vous devez comparer et observer comment les valeurs de sortie varient pour différents cas au fur et à mesure que nous avançons dans ce didacticiel.

Tracer la sortie d'Apache Bench

Ici, nous allons tracer le résultat pertinent pour voir combien de temps le serveur prend à mesure que le nombre de demandes augmente. Pour cela, nous ajouterons le-g option dans la commande précédente suivie du nom du fichier (ici out.data) dans lequel les données de sortie ab seront sauvegardées -

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

Voyons maintenant le out.data avant de créer une intrigue -

$ less out.data

Output

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

Voyons maintenant les en-têtes de colonne dans le out.data fichier -

  • starttime - Il s'agit de la date et de l'heure auxquelles l'appel a commencé.

  • seconds - Identique à l'heure de début mais au format d'horodatage Unix (date -d @ 1496160697 renvoie la sortie de l'heure de début).

  • ctime - C'est l'heure de connexion.

  • dtime - C'est le temps de traitement.

  • ttime - C'est le temps total (c'est la somme de ctime et dtime, mathématiquement ttime = ctime + dtime).

  • wait - C'est le temps d'attente.

Pour une visualisation illustrée de la manière dont ces éléments multiples sont liés les uns aux autres, jetez un œil à l'image suivante -

Si nous travaillons sur un terminal ou lorsque les graphiques ne sont pas disponibles, gnuplotest une excellente option. Nous le comprendrons rapidement en passant par les étapes suivantes.

Laissez-nous installer et lancer gnuplot -

$ sudo apt-get install gnuplot  
$ gnuplot

Output

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

Comme nous travaillons sur le terminal et supposons que les graphiques ne sont pas disponibles, nous pouvons choisir le terminal stupide qui donnera une sortie en ASCII sur le terminal lui-même. Cela nous aide à avoir une idée de ce à quoi ressemble notre intrigue avec cet outil rapide. Préparons maintenant le terminal pour le tracé ASCII.

gnuplot> set terminal dumb

Output

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

Comme notre terminal gnuplot est maintenant prêt pour le tracé ASCII, traçons les données du out.data fichier -

gnuplot> plot "out.data" using 9  w l

Output

1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9 ****** +
       |                                                                   |
  1200 ++                       ********************************************
       |     *******************                                           |
  1000 ++    *                                                            ++
       |     *                                                             |
       |     *                                                             |
   800 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   600 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   400 ++   *                                                             ++
       |    *                                                              |
   200 ++   *                                                             ++
       |    *                                                              |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

Nous avons tracé le ttime, temps total (en ms) de la colonne 9, par rapport au nombre de requêtes. On peut remarquer que pour les dix requêtes initiales, le temps total était de près de 100 ms, pour les 30 requêtes suivantes (de la 10 ème à la 40 ème ), il est passé à 1100 ms, et ainsi de suite. Votre intrigue doit être différente en fonction de votreout.data.