Bien que certaines applications soient faîtes pour une utilisation mono utilisateur, la plupart sont destinées à accueillir des centaines, des milliers d’utilisateurs simultanément, utilisateurs qui eux même ont la possibilité de réaliser des milliers d’interactions différentes. Comment alors tester le comportement de son application dans les pires situations, sans attendre que le chaos ne vienne s’imposer de lui même une fois l’application mise en production ? C’est le sujet de ce billet. Ce qui est présenté ci-dessous interessera les développeurs PHP mais aussi tous ceux qui utilisent une autre technologie web.

Apache AB

Commençons par faire stresser un petit peu notre application…  AB, pour Apache HTTP server Benchmarking tool, permet de simuler des accès au serveur web, en exécutant le nombre de requêtes souhaité par le biais d’un certain nombre de connexions concourantes, elles aussi contrôlées.  AB permet sans soucis de passer des serveurs proxy, simuler les requêtes GET comme POST, gérer l’authentification HTTP… La commande que j’utilise le plus souvent est la suivante :

> ab -e output.csv -n 10000 -c 100 http://docbook:80

Quelques explications sur les options utilisées ici :

• -e : spécifie un fichier CSV de sortie
• -c : nombre de connexions concourantes
• -n : nombre de requêtes à exécuter (réparties entre les différentes connexions)

Je vous invite à lire la très claire page de documentation pour découvrir toutes les options disponibles. Une fois exécutée, cette commande nous livre la sortie suivante :

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

Benchmarking docbook (be patient).....done

Server Software:        Apache/2.2.9
Server Hostname:        docbook
Server Port:            80

Document Path:          /
Document Length:        4427 bytes

Concurrency Level:      100
Time taken for tests:   5.569 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      472500 bytes
HTML transferred:       442700 bytes
Requests per second:    17.96 [#/sec] (mean)
Time per request:       556.946 [ms] (mean)
Time per request:       55.695 [ms] (mean, across all concurrent requests)
Transfer rate:          82.85 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:   246  548 110.6    539    1150
Waiting:      246  547 109.9    538    1147
Total:        247  548 110.6    539    1150

Percentage of the requests served within a certain time (ms)
  50%    539
  66%    564
  75%    578
  80%    591
  90%    633
  95%    673
  98%   1101
  99%   1150
 100%   1150 (longest request)

La ligne sur-lignée est à mon avis celle qui donne le plus de sens aux résultats. Le nombre de requêtes par secondes est en effet un bon indicateur de la santé de votre application (et de votre serveur). Quant au fichier CSV généré, dont on a un aperçu avec les pourcentages donnés à la fin de la sortie ci-dessus, vous pourrez y retrouver la répartition des timings dans lesquels ont été satisfaites les requêtes. Ajoutez à cela des taux de transferts, des erreurs détectées potentielles, et vous obtenez ici un bon outil de benchmarking.

Comment simuler l’envoi de données ?

Comme indiqué dans sa présentation, il est possible de simuler la soumission de formulaires via l’option -p POSTFILE. Une question très récurrente revient souvent : à quoi ressemble ce fichier POSTFILE ? En fonction de la version utilisée, la documentation d’Apache peut ne pas être très bavarde. Ce fichier comprend la liste des arguments de la manière suivante : nom=valeur&nom2=autrevaleur, avec l’encodage spécial utilisé pour les URL.

Pylot

Graphique généré par Pylot : temps de réponse en fonction du temps écoulé

Écrit en Python, Pylot possède a 2 plusieurs pour séduire : la capacité de générer des graphiques, la présence d’un GUI pour les allergiques au mode console, interfaçage XML-RPC… Pylot fonctionne par le biais de scénarios, des test-cases, écrits au sein de fichiers XML pas trop compliqués. Ce mode de fonctionnement permet de personnaliser assez facilement les scénarios et de passer tous ces test-cases automatiquement. Découvrez Pylot sur http://www.pylot.org/.

C’est trop long !

Ces tests vous ont permis de vous apercevoir d’une chose : votre application met systématiquement un minimum de 400 ms à répondre, et facilement jusqu’à 900 ms dès que plusieurs utilisateurs effectuent des recherches. Des temps qui rapidement risquent d’énerver vos utilisateurs. Comment alors réduire autant que possible ces timings fous ?

Premièrement, l’utilisation d’un accélérateur PHP peut être tout a fait adaptée (tout du moins, pour les développeurs PHP). APC, eAccelerator et consorts devraient vous intéresser. Laissez vous guider par les tests et comparatifs (un lien : iPerSec). Ces accélérateurs donneront un coup de boost magique à votre projet PHP.

Des « erreurs », ou lourdeurs de développement, peuvent être à l’origine de la lenteur de l’application. Ré-écrire et optimiser son code peut s’avérer extrêmement long. Avant ça, un petit tour vers une étape de profiling est indispensable. Pour ceux qui ne savent pas de quoi je parle, jetez un oeil sur mon article dédié à XDebug. Cette étape de profiling vous permettra de détecter une éventuelle partie de code particulièrement et anormalement consommatrice de temps.

Et finalement, si c’est encore possible, prenez le temps nécessaire pour analyser la source de la lenteur, la corriger, pratiquer le refactoring de code, installer des serveur proxy, refaire des tests plus précis, modifier la configuration PHP, etc. Un prochain article sera l’occasion d’aborder ces même tests dédiés à MySQL. Et si vous n’avez plus le temps pour corriger tout ça, et bien c’est le moment de prendre de bonnes résolutions et de mettre en place toutes les bonnes pratiques de ZeTechnology pour votre prochain projet !

Aujourd’hui, je vous propose, et vous n’avez pas vraiment le choix, de découvrir la manière dont je teste le déploiement de l’application. Quels sont les pièges, les méthodes, bref, tout.

Virtualiser, c’est la mode.

Je ne possède pas de serveur de test. Et de toute manière, si j’en possédais un, je me servirais tout de même d’un système virtualisé, afin d’éviter d’utiliser inutilement le vrai serveur. Voilà donc le premier point : le déploiement est testé en conditions réelles au sein d’une machine virtuelle. Le système virtualisé est le plus proche possible de celui qui tourne en production : OS, noyau, mémoire disponible, swap, version de PHP, MySQL, fichiers de configuration…

Serveur Debian virtualisé, lancé depuis WindowsXP

Cette précaution permet de s’affranchir au maximum des mauvaises surprises liées à l’environnement. Imaginez un peu, votre système sur lequel vous développez possède le paramètre memory_limit fixé à 128M. Tout fonctionne parfaitement. Sans passer par le scénario de test de déploiement présenté ici, vous décidez de mettre tout de suite à jour la version en production. Tout fonctionne parfaitement. Erreur. Tout semble fonctionner parfaitement. C’était sans compter cet utilisateur qui, voulant lister 100 résultats de recherche par page, obtient une magnifique erreur d’explosion de la mémoire allouée, dont le maximum était fixé à 64M sur le serveur de production.

Quelle solution choisir ?

Les solutions de virtualisation ont le vent en poupe actuellement. Citons VM Ware, VirtualBox, Parallels (MacOSX)… Pour laquelle opter ? Après un essai des différentes solutions, je ne peux que vous conseiller la solution de Sun (Oracle…) : VirtualBox. Disponible sous toutes les plate-formes, gratuite, libre, cette box magique satisfaira toute nos exigences. Une fois installée, installez votre système virtualisé (dans mon cas : Debian 5.0), installez / configurez vos applications (ici : Apache 2, PHP 5.3 + modules, MySQL 5.1, symfony 1.2).

Envoyer ses fichiers au serveur

C’est bien joli d’avoir maintenant une réplique de son serveur de production, mais comment y tester son application ? Plusieurs solutions :

1. Vous recodez intégralement votre projet au sein de votre serveur virtualisé (…)
2. Vous avez pris la bonne habitude d’utiliser un serveur CVS, SVN ou Git. Dans cas là, un commit d’un côté et un update de l’autre fera très bien l’affaire.
3. Vous avez configuré un répertoire partagé sous VirtualBox, accessible aussi bien sous votre système hôte que depuis votre serveur. Placez donc juste l’archive du projet à tester dans ce répertoire.

Et maintenant, je fais quoi ?

Pour résumer, vous possédez maintenant une version à jour de votre application, disponible sur un serveur (virtualisé), réplique parfaite (normalement) du serveur qui l’accueillera. Et bien, rappelez vous pourquoi vous venez de faire toutes ces manipulations : pour tester ! Suivez donc la procédure de déploiement de votre application que vous avez pu décrire au sein de votre documentation. Pour certains projets, il n’y a rien à faire de particulier, le projet est directement fonctionnel, mais pour d’autres, c’est le moment de vérifier que votre documentation, bêtement suivie à la lettre, permet d’arriver à une application qui fonctionne ; quelques exemples en vrac :

• Configuration de l’accès au SGBDR
• Droits en lecture/écriture de certains répertoires
• Mises à jour de fichiers
• Exécution de requêtes pré-requises

Si, une fois, les instructions de la documentation suivies, votre application ne fonctionne pas, c’est qu’il y a bien un problème, lié à la documentation ou à l’application.

Youpi ! Ça fonctionne !

Allons allons, calmons nous. Le déploiement du projet (ou de la mise à jour) fonctionne. Nous ne sommes pas encore en mesure de savoir si le projet fonctionne à 100% comme il devrait. Il vous faut maintenant torturer votre application dans tous les sens afin de déceler les bugs éventuels. Ou alors, et je vais peut-être créer une certaine frustration en m’arrêtant ici, c’est le moment de lancer vos 2000 tests unitaires et fonctionnels, qui vérifieront automatiquement le bon fonctionnement de votre application sur le système courant.

Virtualiser, encore +

Il est fort possible que votre application ne soit pas destinée à une plate-forme en particulier mais  à être déployée sur un grand nombre de serveurs très différents, aux versions et configurations de PHP différentes. Vous pouvez alors virtualiser d’autres OS, aux configurations différentes. Ou vous pouvez pousser la virtualisation encore plus loin en optant pour VServer. Une fois VServer installé sur votre serveur de test, vous serez en mesure d’isoler parfaitement différents « sous-environnements » différents et de switcher d’une configuration à une autre extrêmement facilement, rapidement, et de manière très fiable, sécurisée parfaitement isolée.

En bref :

1. Installez VirtualBox
2. Virtualisez l’OS de votre choix
3. Configurez cet OS virtualisé
4. Testez, lancez vos tests

On regrette très vite de ne pas tester son application. Pendant les différentes phases du développement, il est on ne peut plus utile d’avoir un aperçu fidèle à la réalité de la qualité du produit qu’on s’apprête à délivrer.

Tests unitaires, tests fonctionnels. tests de déploiement, tests de non-régression… la batterie n’est pas mince, et automatiser un maximum de tâche s’avère payant.

La raison d’exister de cette nouvelle série d’article ne vas pas être de vous présenter une énième fois des cours théoriques sur les méthodologies de tests, mais de faire le point sur certaines problématiques, et d’apporter un élément de réponse parmi tant d’autres : le mien.

Vous retrouverez donc dès la rentrée une série d’articles sur cette passionnante thématique, permettant à chacun d’améliorer :

• sa productivité
• la qualité de son travail
• ses habitudes de développement

Le premier article est prévu pour la fin du mois, avec un case-study sur la manière dont je teste le déploiement de Piwam.

PS : Vous noterez les images très très drôles qui accompagneront dorénavant les articles dans la mesure du possible.

Aujourd’hui, je connais le mot de passe d’une caisse… d’UPS ! La personne à l’accueil l’a tout simplement dicté à une collègue à pleine voix, alors que je passais chercher un colis.

Une caisse plutôt isolée, bah oui, « y a un mot de passe » (il paraît)…

• Etourderies, comme un léger refactoring de code dans lequel on inverse une condition (!)
• Fatigue au moment de la correction
• Fautes de frappes stupides

Je ne vous cache pas la honte qui montait en moi lorsque j’ai découvert que j’étais en train de distribuer une version avec un bug empêchant la création même d’une association… Bon, c’était une version alpha, mais quand même, Un simple petit coup de

> symfony test:functional front

aurait permis de s’apercevoir que ça ne marchait plus. Promis, les prochaines releases seront testées peut être… Les tests fonctionnels avec Symfony