Imaginons que vous ayez la chance de voir une page de votre site repris par un très gros site, type pcinpact.com. Si avec un peu de chance le sujet plaît, comme le monsieur tout nu de la redoute, alors votre site va littéralement crouler sous les connexions.

En soit, ça ressemblerait plutôt à une bonne nouvelle.

Le risque, c’est de se retrouver avec un serveur à genoux dès les premières minutes de la publication de la news. Passant à côté de la visibilité que cela pourrait procurer à votre site. Pire, si vous êtes un peu à la traîne, votre news ou article risque de passer presque inaperçue.

Cela est tellement régulier sur le site de pcinpact, que les lecteurs de ce très bon site d’information appellent cela l’effet pcinpact.

Vous l’aurez compris, je suis lecteur de PCInpact depuis de nombreuses années et j’ai vu plus d’un site s’écrouler en quelques minutes. Je suis certain que d’autres sites doivent produire les mêmes effets, avec la terminologie qui va bien.

La reprise d’un bon article ne prévenant généralement pas, l’effet PCInpact s’apparente à un effet uppercut pour ceux qui n’ont pas pris le temps de tester la montée en charge de leur serveur web.

Ça tombe bien, la fondation Apache met à notre disposition un petit logiciel magique, au doux nom d’AB pour Apache Bench.

Rassurez-vous, ce logiciel est bien supérieur à ce que la maison de production a l’habitude de nous fournir.

Prêt pour votre premier baiser langoureux avec votre serveur web ? 😉

Test de montée en charge ?

Le test de montée en charge fait partie de la famille des scenarii de test de performance d’un serveur.

Dans le cas qui nous intéresse, partons du principe que nous sommes un site recevant entre 1 000 et 2 000 connexions quotidiennes sans problème et que nous serons amenés à gérer des pics de connexion pouvant atteindre plusieurs centaines de connexions en un laps de temps très réduit, disons une à deux heures. Le scénario de test nous intéressant le plus sera le teste de montée en charge ou de performance.

Un test de montée en charge serveur est donc la simulation de nombreuses connexions, sur un temps pas trop long quand même.

Dans la famille des tests de performance, Wikipédia nous informe de l’existence :

• Des tests de dégradations des transactions,
• Des tests de stress,
• Des tests de robustesse, d’endurance et de fiabilité,
• Des tests aux limites,
• …

Pour réaliser ce type de test soit vous embauchez 600 intérimaires pour qu’ils se connectent sur votre site, soit vous possédez votre propre réseau d’ordinateurs zombies.

Avec AB, la fondation Apache a pensé à tous ceux n’ayant ni l’un, ni l’autre. Sympa le libre non ?

La fondation Apache

Avant de vous parler d’AB, permettez moi de faire un bref laïus sur la fondation Apache.

Pour ceux qui auraient comme un léger doute, oui Apache est bien le nom du serveur web le plus installé dans le monde. La fondation Apache, c’est l’entité qui assure l’assise et la pérennité financière de ce projet, mais également de nombreux autres, qui ne sont pas tous liés au monde du serveur web.

Un petit exemple pour vous prouver l’étendue que recouvre la fondation dans le monde du logiciel libre.

Je me souviens – ouch – avoir dû utiliser le SVG dans un programme en Java pour un projet d’étudiant. Devinez où nous avons trouvé les classes pour gérer cela ? Chez la fondation Apache. Plus précisément grâce au projet Batik.

Tout ça pour dire que la fondation Apache est un grand acteur du monde du libre, même si la licence n’est pas de type GNU.

AB

Pour le coup, le projet qui nous intéresse est un projet très axé serveur web. Après tout, on est jamais mieux servi que par soi-même il parait.

Grâce à une simple ligne de commande, vous pourrez simuler en quelques secondes un test concret de montée en charge.

Mon petit doigt me dit que pour un grand nombre d’entre vous, les mots lignes de commande et simple sont tout simplement antinomiques.

Ne partez pas, je vous assure que même sous Windows, cela reste un jeu d’enfant. Enfant un peu technophile sur les bords tout de même. AB se trouve livré avec Apache. Ainsi, il vous faudra avoir Apache d’installé sous la main.

Pour nos amis lecteurs windowsiens, je vous conseillerais d’installer XAMPP. AB se trouvera alors dans ./apache/bin/ab.exe.

La ligne de commande ab -n 700 -c 25 www.insidedaweb.com/ – notez bien le / à la fin – signifie générer 700 connexions, -n 700, par groupe de 25, -c25, sur la page www.insidedaweb.com/, notre page d’accueil.

Cette commande est la manière la plus simple de lancer un test bien bourrin, histoire de voir si ça passe… ou ça casse.

Pour la petite histoire, j’ai déjà mis à genoux ce site lorsqu’il était hébergé sur un VPS. Attention à ne pas trop vouloir pousser trop loin, sous peine de bloquer votre site un petit moment.

La direction décline toute responsabilité.

Arrêtez-vous aux premiers signes avant coureurs d’indisponibilité.

Un dernier conseil. Lancez ces tests à une heure que vous savez généralement calme pour votre site. La plage 3h – 5h est celle qui correspondrait le mieux pour nous. Ce qui doit aussi être le cas de pas mal de sites francophones… ou pas. Si vous êtes plutôt du genre aventurier ou du genre marmotte, vous pouvez aussi lancer ce type de test à une heure de forte audience. Au moins, ca sera un test grandeur nature.

Voici ce que donne notre petit test :Lecture des résultats d’AB

Pour notre test, nous avons généré la connexion de 25 personnes simultanées, pour 700 visiteurs au total. Comprenez par là qu’AB générera un premier flux de 25 connexions, puis maintiendra ce flux constant, renvoyant une nouvelle requête dès qu’une du lot en cours d’exécution sera terminée. Il n’attendra pas que le premier lot de 25 soit terminé pour en renvoyer à nouveau 25.

Regardons d’un peu plus près la sortie d’AB suite à notre petit test.

Nous sommes ici au début du test. Vous verrez s’incrémenter les lignes au fur et à mesure de la réalisation des tests. Cela prendra le temps que votre serveur mettra pour tout traiter.

Le premier retour est de type informationnel sur le nom du serveur web utilisé, le nom de domaine, ainsi que le port et le nom du document appelé, ici la racine du site. Enfin, AB nous indique le poids de cette page.

Petit rappel du nombre de connexions simultanées utilisées pendant le test ainsi que le temps que le test a pris. La donnée time taken for tests fait partie des informations à noter.

Résumé du nombre requêtes correctement réalisées, du nombre de requêtes en erreur et du nombre d’erreurs d’écriture. Ici aussi, relevez ces informations. L’idéal étant que toutes vos requêtes aient abouties.

Résumé du nombre de donnée échangées lors de ce test.

Résumé du nombre de requêtes que le serveur a été capable de traiter par seconde, du temps moyens pris par une requête pour s’exécuter en millisecondes, et taux de transfert.

Si quelqu’un dans l’assistance pourrait nous expliquer précisément la différence entre la ligne deux et trois… je suis preneur 🙂

La documentation est un peu pauvre sur l’interprétation des résultats. Cette dernière partie reste quelque peu sombre. Merci pour vos éclaircissements.

 

Ces résultats ne seront pas exactement les mêmes sur l’ensemble des pages de votre site en fonction, par exemple, du nombre de requêtes exécutées.

Voici le même test, réalisé sur une page plus légère.

AB est un programme qui peut faire bien plus que simplement générer de nombreuses connexions. Mais avec une seule ligne de commande, nous sommes en mesure de faire un test grandeur nature… en quelques minutes.