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

…même pour ses projets personnels. C’est en tout cas ce que je pense, plus l’aventure Piwam continue. Mais au fait, qu’est-ce qu’une roadmap ? À traduire par « feuille de route », c’est un document traçant la suite probable (et souhaitable !) du projet. On y retrouve, entre autre :

• Les dates de publication des différentes releases
• Les fonctionnalités prévues pour chacune d’entres elles
• Les objectifs à atteindre
• La politique générale quant à l’évolution du projet

Il n’y a aucune règle précise, c’est un document qui peut circuler en interne uniquement, et/ou être communiqué publiquement afin que tout le monde puisse avoir un aperçu de l’avenir d’un produit, d’une marque, etc.

Maintenant que nous avons la même définition de roadmap, pourquoi est-il à mon sens important d’en adopter une même pour un petit projet personnel ? Pourquoi un petit projet comme Piwam, développé pour le moment par une seule personne, possède-t-il une feuille de route à l’instar des grandes marques ou des logiciels phares de l’industrie, du libre comme propriétaire ?

Taradamdam, les arguments que j’avance ici sont les suivants :

• Entre-nous, je ne vous le cache pas : ça ne coûte rien. À part une petite heure de réflexion.
• Ça fixe un tant soit peu le devenir de votre produit. Va-t-il se doter de tout plein de fonctionnalité ? Va-t-il se contenter d’une release annuelle avec des correctifs de bugs ?
• C’est très bête, mais ce document confère une extraordinaire motivation supplémentaire. On veut -instinct naturel- tenir ses engagements.
• En le rendant publique, il s’agit là d’un bon moyen de communication avec vos utilisateurs.

Une dernière chose à savoir, votre roadmap peut très bien évoluer à tout moment. Rien ne vous empêche de revoir à la baisse ou à la hausse vos objectifs si vous estimez que ces changements ont lieu d’être.

À vos roadmaps !

Pour en savoir +…

• Un exemple : la roadmap de Piwam
• Un autre exemple : la roadmap d’eZ Publish
• Définition sur Wikipedia

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.

Sismo est un outil d’intégration continue développé par Sensio Labs (vous savez, symfony…). L’intégration continue, c’est la possibilité de détecter tout ce qui ne va pas au fil des versions. Du vert ou du rouge, ça passe ou ça ne passe pas, Sismo présente une interface très simple permettant de contrôler le comportement de ses projets au fil des releases. Fabien Potencier a annoncé sur le groupe de discussion « symfony developers« , une éventuelle disponibilité de ce projet libre à la fin du mois de juin.

Une démonstration en ligne du produit est disponible sur http://ci.symfony-project.org. Hâte d’essayer cette alternative à Xinc et consorts.

En revanche, tout ce qui a attrait aux données produites par l’utilisateur me semble être un réel problème. Imaginons, par exemple, un système de gestion des droits qui est intégralement reconstruit from scratch.
La version 1 est basée sur un système de groupes prédéfinis (administrateur, modérateur, utilisateur), et la version 2 va être basé sur un système d’ACL (on définit précisément qui a le droit de faire quoi sur quelle partie du produit). L’utilisateur doit alors mettre à jour son logiciel, mais également sa source données (Base de données, fichiers…) !

Premier problème : il y a fort à parier que la manière de stocker ces données (le schéma) ait subit des altérations non néligeables. Il faut ainsi mettre à jour la source de données de l’utilisateur.

Second problème : Je suis également prêt à parier que l’utilisateur s’en verrait frustré s’il perdait toutes ses données. À l’inverse du logiciel lui même qu’il suffit très souvent de remplacer bêtement, la base de données doit évoluer de manière très contrôlée. Cela impose du coup de développer ses propres outils de migration. Que de temps « perdu » ! Sans compter le risque d’introduire des erreurs au niveau de cette évolution.

Quelques solutions : J’ai bien envie de vous laisser sur cette note de poésie :

Mais plus que ça. La moindre évolution doit être pensée et repensée pour éviter de se retrouver face à de nouveaux problèmes ultérieurs. Quitte à fournir une évolution majeure de votre produit qui engendrerait de tels boulversements, essayez de fournir UNE unique nouvelle version intégrant toutes les évolutions possibles, de telle sorte à éviter à l’utilisateur de futures mises à jour trop lourdes. Pour finir – et c’est tout bête – n’oubliez pas d’alerter l’utilisateur quant à ces modifications. Fournissez aussitôt que possible des outils d’import / export des données manipulées par votre application afin de permettre à l’utilisateur, dans le pire des cas (!), de revenir à la version précédente et de récupérer des données opérationnelles.

Cet article était une application directe de ce que j’ai dû subir récemment avec Piwam… La gestion des cotisations a subi un léger changement mais qui imposait une modification de la base de données. Même s’il s’agissait d’une beta, impossible de ne pas fournir d’outils aussi minimes soient-ils pour assurer le bon fonctionnement de la nouvelle mouture.