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
tmpfspour 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 ;)
Trackbacks
Pour ajouter un trackback (retrolien) sur ce ticket, utilisez cette adresse: http://www.metal3d.org/index.php/trackback/default/tb?id=blog%2F64
De mon coté, une fois APC activé, le montage en tmpfs du répertoire temp/ ne donne rien (logique).
Toutefois, je n'utilise pas de cache "non php".
Que de bons conseils en tout cas :-)
En fait, APC fait à peu près ce qu'un tmpfs peut faire. L'intérêt du cache "fichier" dans tmpfs est que tu peux le lire ton cache comme un fichier, le vider à la main, etc...
Enfin, je pense que APC est bien plus optimal ;) Mais de mon coté il me fait perdre de la perf...
Faudrait que je vérifie ma conf tiens :)
PS: je vais bientôt mettre un truc pour lire les commentaires de billet... je pense que tu vas pas voir que je t'ai répondu
C'est particulièrement étrange que APC te fasses perdre des perfs..... sauf bug, ça me parait limite impossible en fait :-)
Oui, ça vaut le coup de vérifier ta conf !