Optimiser son application web en jouant sur PHP, MySQL et Apache2

Après avoir bien optimisé toute la partie frontend de mon site au sens HTML, CSS, JavaScript, etc, je me suis penché sur les aspects plus techniques et technologiques. Je parlerai donc de PHP, de MySQL, de serveur Apache2, de Memcached, d’Opcode mais aussi d’architecture applicative.

Pour pouvoir travailler dans de bonnes conditions j’ai loué un serveur dédié virtuel (VPS) chez Gandi. L’offre actuelle est composée de parts, une part représentant environ 1/60ème d’un gros serveur. J’ai choisi ce type de serveur car je n’ai pas réellement besoin d’un full dédié mais aussi pour l’architecture scalable fourni. En effet, il est possible de rajouter des parts à la volée, ponctuellement ou de manière programmée. On peut ainsi pallier une grosse surcharge automatiquement même si le temps de déclenchement est trop élevé (dépassement du seuil défini pendant 20 minutes au moins).

Installation et configuration

J’ai donc pris une part, vierge de toute installation à l’exception de la distribution Linux, Debian 5 dans mon cas. J’ai commencé par installer les services web utiles : Apache2, MySQL, PHP 5.3 et PhpMyAdmin. Ensuite, j’ai installé APC via la commande PECL (pour PHP 5.3 on veillera à bien prendre apc-beta). J’ai également installé Memcached et l’extension qui va bien pour l’utiliser avec PHP. Je passe les aspects configurations de sécurité du serveur en lui-même mais voilà ce que j’ai fait pour chaque application :

Apache2

Niveau configuration, rien n’a été modifié mis à part les vhosts et un paramètre dont je donnerai les détails plus bas. Du côté des modules, j’ai installé ceux qui vont bien : deflate,expires, headers, mem_cache, rewrite et php5.

MySQL

Aucune modification, sauf l’activation des logs lors des phases de test. Pour cela, on modifie le fichier my.cnf dans /etc/mysql/.

APC

Il faut l’activer dans le fichier php.ini :

Puis le configurer :

Permet d’éviter les appels disque.

Définit l’endroit où sont stockés les fichiers de cache. Ici j’utilise un Ramdisk de 32Mo même si ce n’est pas forcément utile car APC utilise de base un segment de mémoire partagé. A voir plus bas une note à ce sujet.

Pour créer un Ramdisk, il faut utiliser le système de fichier tmpfs. Un exemple de ligne à insérer dans /etc/fstab :

Memcached

On ne touche à rien excepté la taille alloué que j’ai passé de 32Mo à 16Mo : suffisant et avec 256Mo de base, le mieux est de se restreindre.

Phases de tests

Avec tout ceci, j’ai pu faire des tests et voir ce que permettait un tel serveur. J’ai fait des Apache Bench (ab) de plusieurs manières. Les premiers n’ont pas été glorieux, un simple ab 200/5 donnait moins de 2 requêtes par seconde. Très mauvais du coup. De ce fait, trois pistes :

- Problème matériel : CPU trop faible, RAM insuffisante, lenteurs des accès disques.

- Problème logiciel : Apache2 mal configuré, MySQL saturé.

- Problème sur l’application en elle-même.

Point numéro 1 : Via @mrboo, je savais à quoi m’attendre et comme je n’ai pas le choix, je dois me contenter de ce que j’ai et l’optimiser. (Je fais le choix de tester une part unique). Au niveau des accès disques, ce type de serveur obtient de bons scores. Puis un simple htop me montrait bien qu’il se passait quelque chose ailleurs.

Point numéro 2 : MySQL est en quelques sortes protégé par Memcached puisque ce dernier stocke les résultats des requêtes SQL pendant un certain temps t. Ce n’est pas là que ce situe le problème.

Au niveau d’Apache2, j’ai modifié le paramètre KeepAlive en le positionnant à Off. Ce changement m’a permis de gagner énormément et d’obtenir des résultats convenables.

Point numéro 3 : Au niveau de mon application j’ai repensé la couche d’accès aux données. En effet, j’avais dans un premier temps ajouté le cache Memcached à PDO. C’est un tord puisque les connexions se faisaient toujours (même si derrière, aucune requête n’était exécutée). C’est pourquoi j’ai modifié ce petit point en testant d’abord l’existance de résultats dans le cache et cas échéant en ouvrant ensuite une connexion à la base de données et en intérrogeant MySQL.

Memcached fonctionne sur un système clé/valeur : je stocke le hash md5 de la requête SQL et son résultat correspondant, j’ai également pris soin d’utiliser la compressionMemcached disponible.

De plus, j’ai optimisé mes requêtes SQL ainsi que mes tables de base de données.

Après de tels changements voici les résultats obtenus :

200 requêtes, 1 en concurence : 6,97 requêtes par seconde.

200 requêtes, 5 en concurence : 6,65 requêtes par seconde.

A ce niveau là, le serveur encaisse bien (du moins à mon échelle).

Ramdisk or not Ramdisk avec APC

Au niveau d’APC j’ai testé l’utilisation d’un Ramdisk :

Puis l’utilisation sans Ramdisk par APC. Le résultat est meilleur :

On utilisera donc un Ramdisk avec les Opcodes type eAccelerator mais pas avec APC. Après réglage de ces détails, le serveur passe la barre de 7 requêtes par seconde avec des temps de réponse assez plaisants :

Toujours mieux avec 5 requêtes concurrentes :

Ensuite dans les benchs plus importants :

Moins satisfaisant même si le serveur répond bien, il met plus de temps et perds quelques requêtes…

Un ab 1000/100 me donne les résultats suivants :

- 4,42 requests/second

- 14% d’échec

- 66% des requêtes en moins de 6s

Plus loin dans les optimisations

Dernière option, mettre le repertoire de cache en Ramdisk, cette fois-ci c’est très bénéfique et un ab 200/1 passe à 7,21 requêtes par seconde. Et un ab 200/5 passe à 6,97 requêtes par seconde en ayant 98% des requêtes traitées en moins de 3s.

Webwait obtenu : Average load time after 10 runs : 0,41s.

Après cela, j’ai réfléchi à ma gestion des ressources. Aidé par @madmatah, je me suis intéressé à la configuration Apache2 et au MPM Prefork. Après une série d’Apache Bench, j’ai configuré ce module comme suit :

J’ai également passé le timeout à 2 secondes. Le load average devient ainsi inférieur à 1. Pour surveiller le load average ainsi que les utilisations de la RAM et du SWAP je me suis servi de la commande

mais aussi de

Au final, j’ai modifié mes premiers essais :

- Le Ramdisk est passé de 32Mo à 4Mo. Il stocke désormais le cache HTML de mon site.

- Memcached est lancé avec 8Mo alloués.

Par contre le KeepAlive est toujours sur Off. J’ai de gros soucis dès que je le passe à On…

Dernière optimisation faite : l’ajout des options de montage noatime et nodiratime sur mes volumes dans /etc/fstab.

Conclusion

Le manque de puissance CPU se fait énormément ressentir. Au niveau RAM, on s’en sort très bien car il est rare qu’elle soit saturée. Mais le CPU est très vite à 100% d’utilisation et peine à revenir. Il faudrait voir avec des ressources supplémentaires.

Une telle part reste un bon début pour se faire la main sur un serveur dédié, pas cher, souple et scalable il ne démérite pas.

Cependant, avec l’utilisation de Memcached, on limite les accès base de données (et donc disque). Un serveur RPS chez OVH ne fait pas le poids au niveau de la rapidité d’accès disque face à une part Gandi, il serait intéressant de reprendre ma configuration et de la porter sur un serveur RPS afin d’établir un comparatif. Je pense faire ça le mois prochain.

Pour terminer, j’ai toujours des soucis avec le KeepAlive à On, les temps minimums de traitement d’une requête sont de l’ordre du KeepAliveTimeout…

Voici également deux screens des interfaces de gestion Memcached et APC que j’utilise :

Merci à www.mrboo.fr pour ses tests et retours d’expérience.

Merci à @madmatah pour ses nombreux conseils et son temps.

Le mot de la fin : le site sur lequel vous vous trouvez n’a pas subi les modifications précédentes…

Related Posts

• Dédibox v3 : Nginx + PHP-FPM + Apache2 + APC + Memcached + MySQL
• Réplication MySQL maître-esclave
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• Connaissiez-vous … REPLACE en SQL ?