|
09/03/2001
Les
solutions d'optimisation des serveurs Apache/PHP/MySQL
au banc d'essai
ATTENTION: cet
article a été corrigé le 7 septembre.
Une erreur s'était en effet glissée dans
le paragraphe concernant la comparaison
de Zend Cache et d'Alternative PHP Cache. C'est donc
bien ce dernier - et non Zend Cache - qui affiche un
consommation importante de ressources processeur. Merci
aux lecteurs qui nous ont averti de cette erreur et
toutes nos excuses à Globalis Media Systems.
SSII spécialiste des technologies PHP, Globalis
Media Systems vient de publier un banc d'essai de
quelques unes des solutions d'optimisation des architectures
Apache/PHP/MySQL. Loin d'être exhaustive, ce que
reconnait d'ailleurs la SSII en mentionnant les solutions
qu'elle n'a pas testées, l'étude présente
toutefois le mérite de donner quelques ordres
de grandeur des gains de performance dans un univers
technique (Apache/PHP) largement répandu. L'évaluation
couvre trois types de solutions:
- Les optimiseurs
- Les caches d'opcode
- Les caches de page
La catégorie des optimiseurs se résume
aujourd'hui à Zen
Optimiser. Comme son nom l'indique, cet outil
cherche à optimiser le code des scripts PHP en
changeant par exemple l'ordre des incrémentations
ou en jouant sur l'imbrication des boucles. Les logiciels
de la deuxième catégorie, les caches d'opcode,
s'occupent eux de garder en mémoire l'opcode,
nom donné au code généré
par PHP et qui représente une étape intermédiaire
entre le script et l'exécutable. Deux outils
ont été évalués par Globalis
Media, Zend
Cache et Alternative
PHP Cache (APC). Enfin, du côté
des pages de cache, la SSII s'est penchée sur
jpcache.
Le protocole de test a pris
soin de faire travailler les solutions sur des scripts
très variés. Moralité de l'histoire:
- L'optimiseur de Zend apporte des gains de performance
sur des scripts très particuliers - typiquement
du calcul pur. Pour le reste, son intérêt
est moins flagrant.
- Du côté des caches
de page, Zend Cache surclasse assez nettement
APC qui affiche en outre une consommation plus
importante de ressources processeur. Toutefois, Zendcache
offre moins de possibilité de configuration qu'APC.
Avec ce dernier, il s'avère notamment possible
d'attibuer pour chaque fichier un "timeout"
(délai avant que le fichier ne soit purgé
du cache).
- Mais c'est avec jpcache que les gains de performances
les plus sensibles sont atteints. Là où
les gains des autres solutions oscillent entre 21 et
51% par rapport à un environnement PHP3, les
mesures avec la combinaison PHP4+jpcache affichent des
bénéfices au-delà des 500%. Surtout,
l'outil se montre assez souple pour être utilisé
sur une plate-forme mutualisée: contrairement
à d'autres il ne demande pas de modifier le fichier
php.ini ni de redémarrer le serveur. jpcache
connaît toutefois quelques limites: son intérêt
est moins manifeste pour les sites dont le contenu est
très fréquemment remis à jour et
il impose de glisser un script dans chaque page à
"cacher".
La lecture de ce bench suscite forcément quelques
frustations. On aimerait notamment pouvoir comparer
ces mesures à celles d'un environnement IIS/ASP/SQL
Server. D'autant que IIS et Apache représentent
deux architectures distinctes. IIS gère en effet
des threads là où Apache traite des processus
- contrairement à un processus, entité
autonome en quelque sorte, les threads partagent des
ressources. Conséquence: un processus est plus
long et plus lourd à activer qu'un thread mais
s'avère aussi plus robuste. Voilà pourquoi
un IIS se montre plus réactif pour répondre
aux montées en charge qu'un Apache, mais aussi
moins robuste quand un incident survient.
"Les choses évolueront encore avec Apache
2 qui apportera entre autres le multi-thread, précise
Armel Fauveau, qui a conduit l'étude. Mais pour
comparer finement ces solutions, encore faudrait-il
que nous disposions d'un protocole standard de test
qui définisse une plate-forme serveur et une
bibliothèque de scripts portables". A défaut,
un tel comparatif ne peut être pertinent qu'en
limitant le périmètre des solutions étudiées.
La méthodologie:
L'évaluation a consisté à exploiter
dans un environnement PHP4 les différentes solutions
et certaines de leur combinaisons sur trois tests: accéder
à la la page d'accueil de PHPIndex,
assez typique d'un site dynamique, lancer une requête
dans l'annaire de PHPIndex pour solliciter la base MySQL
et enfin exécuter un calcul des décimales
de PI. De quoi éprouver les solutions sur des
scripts variés. Les performances de chaque combinaison
de solutions ont été mesurées sur
250 requêtes et en augmentant par paliers les
accès simultanés. Les mesures ont été
comparées à celles de deux plates-formes
"brutes" PHP3 et PHP4.
|
