Patrice Ferlet
Patrice Ferlet
Créateur de ce blog.
Publié le mai 13, 2008 Temps de lecture: 4 min

Me suivre sur Mastodon

Optimisations Copix PHP et Apache

Les temps de réponse… Dieu sait à quel point cela est le tracas de bien des administrateurs. Le service Woozweb vous fait faire des cauchemards ? Faites comme moi… optimisez. Je vais vous expliquer ce que j’ai fait pour enfin avoir des temps de réponses corrects et un “performance grade” (YSlow) enfin acceptable.

Avant toute choses, regardez un peu la tête du graph au temps où j’avais encore mon serveur VDS chez Lycos:

Effrayant ? vous l’avez dit… environ 5s de temps de réponse, et des coupures à tout va… autant vous dire que je suis passé chez Dedibox en courant !

Mon YSlow était de 40%. Autant vous dire: médicore. Mon temps de réponse donné par Woozweb me donnait la chair de poule. A peine installé, voilà ce que je voyais:

5 secondes de temps de réponse… bizarre… je fais un tour dans la configuration et me rend compte que j’avais laissé le mode DEVEL de Copix en route… passage en mode PRODUCTION et regardez la suite du graph:

Mieux, largement mieux… Maintenant, 1.4 secondes… mais cela ne me suffisait pas. Je suis donc parti dans une recherche fructifiante de manière d’aller au plus vite pour afficher ma page de blog. D’abord je vous rappelle que j’ai un nuage de tags, un calendrier, des tickets à générer depuis un langage wiki (en général)… et j’avais un peu loupé le cache dans le module.

Comme je vais beaucoup utiliser le répertoire temporaire de Copix je monte ce dernier en tmpfs:

mount -t tmpfs tmpfs /var/www/html/metal3d/temp

Cela permettra au cache de s’écrire dans la RAM et non sur le disque dur. Après refonte des caches et montage de tmpfs, regardez la fin du graph:

Je viens de mettre en prod, 0.4 secondes en moyenne de temps de réponse… Là oui, j’ai optimisé :)

Reste le performance grade. YSlow me sort un 40% désastreux… le poids de la page est lamentablement élevé (près de 500ko). Il faut avouer que j’ai abuser d’images, de texte, et de javascripts… mais cela dégrade le téléchargement des composants.

Une méthode efficace est de gziper le contenu. Seul les éléments “non images” devraient être compressés. Un tour dans apache, module “mod_deflate” activé, et voici ce que j’ai ajouté dans mon httpd.conf:

<Location />
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
AddOutputFilterByType DEFLATE text/html

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Header append Vary User-Agent env=!dont-vary
</Location>

En d’autres termes, je compresse tout ce que je veux envoyer via apache sauf les mp3, avi, etc… et les images. Parce que IE est largement bugué, on ne compressera que les sorties html, idem pour Mozilla 4.

Bref, cette configuration est très à même de compresser le contenu.

Voyons après rechargement de mon Apache ce que donne le performance grade: 59%. Cela correspond à une excelente moyenne au vu du contenu que j’ai à envoyer. Copix gère bien les Etags, et me voilà avec un contenu réduit à **40ko au lieu de 450ko**

Alors les conseils: -si vous en avez la possibilité, utilisez le module mod_deflate de Apache avec la configruation que je vous ai donné au dessus. -utilisez des caches APC (pour PHP) -Utilisez des caches pour la plupart de votre contenu, ne re-générez pas tout le temps le HTML, préférez le stocker quelques heures sur votre disque dur. Copix gère parfaitement cela. -Utilisez les threads pour accélérer les processus qui peuvent se paralléliser (voir Copix module thread) -Utilisez tmpfs pour la plupart de vos répertoires temporaires afin d’accélérer les accès

Cela n’est qu’une petite liste rapide, mais qui va vous faire gagner un temps fou en réponse.

Voilà pour ce ticket, j’espère que cela vous aidera !

PS: Oui je fais de la pub pour Copix, mais ayant tenté de voir ce que faisait d’autres frameworks, je vous assure que ce dernier est largement au dessus des autres en ce qui concerne les performances de réponse. A bon entendeur ;)

comments powered by Disqus