Depluis plus d’un an et demi ce blog ne fait que progresser en taille de base de données (756 posts et un paquet de commentaires aussi). Depuis quelques temps je trouve que le blog est particulièrement long à charger et cela m’énerve profondément…
Voici ce que j’ai fait pour tenter de réduire ce temps de chargement de chaque page :
Sur le blog:
– Premièrement j’ai réduit le nombre de posts affichés sur la home. A l’origine j’affichais 10 posts sur la page d’accueil, aujourd’hui je n’en affiche plus 4. Donc théoriquement je dois gagner 60% de temps de chargement.
– Les images du blog sont plus ou moins optimisée (en général on est autour de 30ko par image), mais elles sont hébergées en dehors du blog et cela ne doit pas m’aider à être plus rapide.
– Quelques appels externes sont faits par des scripts qui tournent sur le blog dont majoritairement des scripts de statistiques comme statcounter, google analytics, W3counter et des outils de monitoring comme crazyegg. Je les laisse parce qu’ils me sont utiles.
Sur la base SQL et le PHP :
– J’ai optimisé la base msql en faisant cette petite manipulation dans phpmyadmin: sélection des tables à optimiser puis en bas dans le menu déroulant « optimiser les tables ». (attention faite un backup de la base avant).
– Un truc qui a l’air très bien pour faire du cache de pages dynamiques est Alternative PHP Cache (APC) qui est un bout de code fait par le papa du php, mais il faut bidouiller le serveur apache de votre hébergement et OVH ne m’autorisera certainement pas cette manipulation.
– Ensuite le code du blog en lui même est ce qu’il est, je ne vais pas m’amuser à toucher à wordpress sinon le blog va commencer à planter sérieusement ;)
Pour tester votre vitesse de chargement de votre blog vous pouvez jetter un oeil à cet outil et ainsi faire des comparaisons de chargement avec d’autres blogs que vous connaissez:
Avec tous ces changements je suis encore lent… Qui aurait une idée pour aller plus vite?
Pour ton cache, sans avoir à bidouiller avec un APC cache, la méthode la plus simple et rapide et d’utiliser le cache de WordPress : met define(‘ENABLE_CACHE’, true); dans le fichier wp-config.php (mais il semble poser problème). Sinon tu peux utiliser le plugin Wp-cache qui est très très bien. Personnellement c’est ce que je fais sur mon blog est le gain est nettement visible (près de 50%) et en plus c’est économique pour la base de données.
J’ai oublié ma stat : 51.6 KB 0.91 seconds 0.02 seconds
JUL c’est une des questions que je me pose en ce moment!
Merci bertrand je vais regarder cela ce we… Quitte à passer sous wp-cache!
Je trouve aussi qu’OVH a des problèmes de lenteur ces temps-ci…
Mais le problème, c’est surtout que ce n’est pas régulier… d’une minute à l’autre, cela varie trop… :(
Ce sont surtout les scripts des services externes qui ralentissent fortement le blog.
Oué, je serais toi j’enlèverai tout, garde que le contenu des billets :p
Oui pour pouvoir optimiser, il faudrait réussir à déterminer quels sont les composants les plus lents!
Si les scripts des services externes comptent pour 80% du temps de chargement, c’est une perte de temps de s’attarder sur les optimisations wordpress ou MySQL…
Essaie de désactiver tous tes scripts pour voir, et réactive les 1 à 1 pour voir le coût unitaire de chaque script.
C’est ce que j’aurais dit Henri, activer la mise en cache de tes pages (un commentaire sur le blog de JF Ruiz explique comment l’activer dans une version 2 ou plus)
La diminution du nombre de billets par page est effectivement la meilleure solution pour accélerer les temps de chargement.
Je viens de passer de 15 à 7 billets, mon temps de chargement a été divisé au moins par trois :-/
Je dirais qu’il faut installer WP-Cache pour un gain non négligeable du côté de l’utilisation des ressources du serveur, et ne garder qu’un seul système de stats JavaScript externe pour limiter l’utilisation des ressources côté client.
Plus d’un service de stats externe en sus des les stats de ton hébergeur, c’est du luxe à mon avis.
Là actuellement pour charger uniquement cette page mon navigateur a téléchargé 558 Ko de données, c’est absolument énorme. Et encore, mon navigateur ne charge pas la majorité des pubs. Sans parler du temps qu’il lui faut ensuite pour parser tout ce fourbi :-)
– Active le slow_query_log de MySQL.
– Regarde les requetes qui sont lentes.
– Crée des index sur les enregistrements qui servent a certaines query slow.
– Vérifie s’il y a des lock qui se crée
– Vérifie ce qui cause les locks
– Isole les requetes de lock ou élimine les.
Si ca semble etre autre chose que MySQL …
– Vérifie le load général du serveur
– Vérifie l’utilisation du CPU
– Vérifie les process Apache
– VÉrifie le RAM libre
Si le serveur n’est plus suffisant …
– Implante du Load Balancing
– Utilise un serveur de base de données séparé (pas le meme que le web).
Ca pourrait aider ….
J’oubliais …
Si ton blog roule encore sur un hébergement mutulisé, passe au dédié. Le réseau semble avoir un ping acceptable … mais bon ca peut aider aussi de trouver un réseau plus performant si tu crois que c’est le problème.
Bon merci à tous je pense savoir quoi faire maintenant ce we ;)
Le plugin wp-cache me fait un paquet d’erreurs donc pour l’instant il n’est pas actif sur le blog :(
D’après ce que je lisais dans les listes de diffusion concernées, OVH aurait normalement un rapport d’au moins 2 en puissance de machines pour faire tourner l’ensemble des sites web mutualisés aux heures de pointe. Cela dit, cela devait aussi être le cas pour le traitement des emails, et une recrudescence du spam a récemment sensiblement ralenti la livraison des messages…
Si ton trafic devait réellement augmenter, il faudrait vérifier si le nombre d’accès à la base de données (limité par ton plan chez OVH) permet de servir tous les visiteurs. Mais a priori, cela devrait être très largement suffisant.
Quelques tests à l’instant (les deux derniers étant hébergés sur mon serveur) :
Si tu tiens à accélérer ton blog, pense surtout à enlever (y compris en les supprimant physiquement de ton espace d’hébergement web) tous les plug-ins WordPress qui ne te semblent pas vitaux. Outre le fait que le PHP est un langage assez lent, les fonctions les plus rapides sont celles qui ne sont pas appelées. ;-)
Pour ce qui est des solutions telles que les caches code PHP, non gérées sur les plans mutualisés d’OVH, il en existe essentiellement deux :
– APC (utilisé notamment par Yahoo!) ;
– eAccelerator.
J’avais essayé eAccelerator sur mon ancien serveur qui m’a fait gagner un rapport 2 de vitesse environ sur le chargement d’une page PHP. Je vais essayer de l’installer de nouveau sur ce serveur, quand j’aurais compris comment ! ;-)
Si vraiment, tu devais rencontrer des difficultés de trafic, WordPress.com propose des solutions d’hébergement de blogs haut de gamme assez hors de prix ! ;-)
Si tu veux, henri, je peux te mettre à disposition un compte sur mon serveur dédié pour faire des tests de performances (P4 Dual Core 3 GHz, 1 Go de RAM, bande passante de 100 Mbps). Il est assez sous-exploité, en ce moment. Cela dit… la continuité du service laisse parfois à désirer, comme je suis un administrateur serveur encore débutant…
Je sais pas si WordPress a cette fonctionnalité, mais sur mon forum tu peux activer une fonction qui sépare le temps des accès Mysql aux requêtes PHP, et t’indique le temps qu’a pris l’un et l’autre.
Ca te permettrait déjà de savoir où ca coince, si c’est au niveau SQL (donc serveur SQL surchargé) ou au niveau PHP (trop de modules? serveur plié?).
En fait voici les erreurs que j’ai avec le plugin wp-cache :
Warning: sem_get() [function.sem-get]: failed for key 0x152b: Permission denied in /home.10.3/XXXXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 81
pourtant le fichier est en permission 777…
Sur le chargement d’une page non présente dans le cache voici les erreurs :
Warning: sem_get() [function.sem-get]: failed for key 0x152b: Permission denied in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 81
Warning: sem_acquire(): supplied argument is not a valid SysV semaphore resource in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 90
Warning: sem_release(): supplied argument is not a valid SysV semaphore resource in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 99
Warning: Cannot modify header information – headers already sent by (output started at /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php:81) in /home.10.3/XXXX/www/wp-includes/pluggable-functions.php on line 272
En fait, c’est très variable … celui de presse-citron n’est pas mieux en fait …
pareil pour loïc le meur
D’après ce que je lis dans la doc d’installation de WP-Cache, le plug-in semble utiliser les liens symboliques. Il est possible qu’Apache sur les plans mutualisés ne gère pas les liens symboliques par défaut. Aussi, tu peux éventuellement tenter d’éditer le fichier .htaccess à la racine de ton blog pour y insérer la ligne suivante :
Options Indexes FollowSymlinks MultiViews
Par ailleurs, la doc de WP-Cache indique que dans l’écran d’options du plug-in, il y a de la configuration à faire ou du moins des messages d’erreur indiquant les étapes à réaliser pour corriger d’éventuels problèmes…
De même, j’ai vu qu tu avais supprimé certains ajouts (feedbutton par ex.).
C’est une bonne idée, je me suis par exemple rendu compte hier que ce bouton mettait un temps affreusement long à se charger… et bloquer le reste de la page. :(
D’ailleurs, je cherche une solution comparable et viable :)
Coté MySQL : vérifier les index ?
Coté PHP : Pour faire du profiling et trouver les plug-in qui consomment le plus je te conseil deux outils simples et très pratiques : Xdebug et wincachegrid.
Comme tu n’as pas un serveur dédié je te conseil d’installer sous windows (compter 10min) Wamp, tu y installe une copie de ton blog (fichiers via FTP, Base via PHPMyAdmin).
Une fois qu’il tourne sur ta machine, tu install l’extention xdebug de PHP (plein de tutoriaux expliquent comment faire, ça prend 5 min).
Enfin tu install wincachegrid qui est un soft opensource de profiling sous windows (5min too).
Et grâce à cela tu aura le temps exact d’execution de chaque partie de script et tu poura déterminer précisément « qui te coute cher ».
Enfin Coté Apache : peux tu activer la compression Gzip pour alleger encore un peu tes pages ?
Loic j’ai en effet viré feedbutton il mettait 3 plombes à charger! Sinon Kwa et mrboo je vais tester vos pistes, merci encore.
mrboo, la compression des pages dynamiques (donc effectuée de A à Z à chaque page servie) n’est que rarement intéressante. En effet, il faudrait que le processeur du serveur soit plus rapide à compresser que la bande passante allouée du côté serveur et du côté client (c’est le plus lent des deux qui ralentit). Généralement, à moins d’avoir des clients dont la connexion Internet est limitée (modem classique, soit environ 10 % des visiteurs de l’un de mes blogs, notamment), la compression n’accélère pas le chargement des pages (à ma connaissance, les serveurs mutualisés de chez OVH sont connectés à 100 Mbps).
kwa> en effet le gain par GZip ne doit pas être énorme, de toutes façons le problème semble plus lié à l’utilisation importante de plugins externes avec des chargements de tout les cotés vers des API plutot qu’un problème de charge CPU ou de Bande Passante.
Avec tous ces changements je suis encore lent… Qui aurait une idée pour aller plus vite?
Quitter OVH ?
Les stats de mon blog chez Gandi donnent :
01 blog.julnav.com 47.21 KB 1.23 seconds 0.03 seconds
Cela fait quand même une sacrée différence !
Pour ton cache, sans avoir à bidouiller avec un APC cache, la méthode la plus simple et rapide et d’utiliser le cache de WordPress : met define(‘ENABLE_CACHE’, true); dans le fichier wp-config.php (mais il semble poser problème). Sinon tu peux utiliser le plugin Wp-cache qui est très très bien. Personnellement c’est ce que je fais sur mon blog est le gain est nettement visible (près de 50%) et en plus c’est économique pour la base de données.
J’ai oublié ma stat : 51.6 KB 0.91 seconds 0.02 seconds
JUL c’est une des questions que je me pose en ce moment!
Merci bertrand je vais regarder cela ce we… Quitte à passer sous wp-cache!
Je trouve aussi qu’OVH a des problèmes de lenteur ces temps-ci…
Mais le problème, c’est surtout que ce n’est pas régulier… d’une minute à l’autre, cela varie trop… :(
01 http://www.69006.com 33.57 KB 1.24 seconds 0.04 seconds
02 http://www.2803.com 41.33 KB 8.38 seconds 0.2 seconds
No comment ;)
Achètes un dédié!
ou partage en un ;-)
Ce sont surtout les scripts des services externes qui ralentissent fortement le blog.
Oué, je serais toi j’enlèverai tout, garde que le contenu des billets :p
Oui pour pouvoir optimiser, il faudrait réussir à déterminer quels sont les composants les plus lents!
Si les scripts des services externes comptent pour 80% du temps de chargement, c’est une perte de temps de s’attarder sur les optimisations wordpress ou MySQL…
Essaie de désactiver tous tes scripts pour voir, et réactive les 1 à 1 pour voir le coût unitaire de chaque script.
C’est ce que j’aurais dit Henri, activer la mise en cache de tes pages (un commentaire sur le blog de JF Ruiz explique comment l’activer dans une version 2 ou plus)
La diminution du nombre de billets par page est effectivement la meilleure solution pour accélerer les temps de chargement.
Je viens de passer de 15 à 7 billets, mon temps de chargement a été divisé au moins par trois :-/
Je dirais qu’il faut installer WP-Cache pour un gain non négligeable du côté de l’utilisation des ressources du serveur, et ne garder qu’un seul système de stats JavaScript externe pour limiter l’utilisation des ressources côté client.
Plus d’un service de stats externe en sus des les stats de ton hébergeur, c’est du luxe à mon avis.
http://mnm.uib.es/gallir/wp-cache-2/
Là actuellement pour charger uniquement cette page mon navigateur a téléchargé 558 Ko de données, c’est absolument énorme. Et encore, mon navigateur ne charge pas la majorité des pubs. Sans parler du temps qu’il lui faut ensuite pour parser tout ce fourbi :-)
– Active le slow_query_log de MySQL.
– Regarde les requetes qui sont lentes.
– Crée des index sur les enregistrements qui servent a certaines query slow.
– Vérifie s’il y a des lock qui se crée
– Vérifie ce qui cause les locks
– Isole les requetes de lock ou élimine les.
Si ca semble etre autre chose que MySQL …
– Vérifie le load général du serveur
– Vérifie l’utilisation du CPU
– Vérifie les process Apache
– VÉrifie le RAM libre
Si le serveur n’est plus suffisant …
– Implante du Load Balancing
– Utilise un serveur de base de données séparé (pas le meme que le web).
Ca pourrait aider ….
J’oubliais …
Si ton blog roule encore sur un hébergement mutulisé, passe au dédié. Le réseau semble avoir un ping acceptable … mais bon ca peut aider aussi de trouver un réseau plus performant si tu crois que c’est le problème.
01 http://www.cyberdeeder.com 19.1 KB 0.77 seconds 0.04 seconds
Youpiiii !
Bon merci à tous je pense savoir quoi faire maintenant ce we ;)
Le plugin wp-cache me fait un paquet d’erreurs donc pour l’instant il n’est pas actif sur le blog :(
D’après ce que je lisais dans les listes de diffusion concernées, OVH aurait normalement un rapport d’au moins 2 en puissance de machines pour faire tourner l’ensemble des sites web mutualisés aux heures de pointe. Cela dit, cela devait aussi être le cas pour le traitement des emails, et une recrudescence du spam a récemment sensiblement ralenti la livraison des messages…
Si ton trafic devait réellement augmenter, il faudrait vérifier si le nombre d’accès à la base de données (limité par ton plan chez OVH) permet de servir tous les visiteurs. Mais a priori, cela devrait être très largement suffisant.
Quelques tests à l’instant (les deux derniers étant hébergés sur mon serveur) :
Domain name / Size / Load time (secs) / Average Speed per KB
http://www.french20.fr 44.29 KB 1.33 seconds 0.03 seconds
http://www.2803.com 40.61 KB 1.23 seconds 0.03 seconds
http://www.presse-citron.net 41.52 KB 1.97 seconds 0.05 seconds
lightpress.org 38.05 KB 0.97 seconds 0.03 seconds
http://www.imazine.fr 99.95 KB 1.67 seconds 0.02 seconds
http://www.loiclemeur.com/france/ 189.04 KB 2.74 seconds 0.01 seconds
unearaigneeauplafond.be 32.89 KB 1.03 seconds 0.03 seconds
blog.lesperlesduchat.com/perles.php 24.83 KB 1.61 seconds 0.06 seconds
Si tu tiens à accélérer ton blog, pense surtout à enlever (y compris en les supprimant physiquement de ton espace d’hébergement web) tous les plug-ins WordPress qui ne te semblent pas vitaux. Outre le fait que le PHP est un langage assez lent, les fonctions les plus rapides sont celles qui ne sont pas appelées. ;-)
Pour ce qui est des solutions telles que les caches code PHP, non gérées sur les plans mutualisés d’OVH, il en existe essentiellement deux :
– APC (utilisé notamment par Yahoo!) ;
– eAccelerator.
J’avais essayé eAccelerator sur mon ancien serveur qui m’a fait gagner un rapport 2 de vitesse environ sur le chargement d’une page PHP. Je vais essayer de l’installer de nouveau sur ce serveur, quand j’aurais compris comment ! ;-)
Si vraiment, tu devais rencontrer des difficultés de trafic, WordPress.com propose des solutions d’hébergement de blogs haut de gamme assez hors de prix ! ;-)
Si tu veux, henri, je peux te mettre à disposition un compte sur mon serveur dédié pour faire des tests de performances (P4 Dual Core 3 GHz, 1 Go de RAM, bande passante de 100 Mbps). Il est assez sous-exploité, en ce moment. Cela dit… la continuité du service laisse parfois à désirer, comme je suis un administrateur serveur encore débutant…
Je sais pas si WordPress a cette fonctionnalité, mais sur mon forum tu peux activer une fonction qui sépare le temps des accès Mysql aux requêtes PHP, et t’indique le temps qu’a pris l’un et l’autre.
Ca te permettrait déjà de savoir où ca coince, si c’est au niveau SQL (donc serveur SQL surchargé) ou au niveau PHP (trop de modules? serveur plié?).
En fait voici les erreurs que j’ai avec le plugin wp-cache :
Warning: sem_get() [function.sem-get]: failed for key 0x152b: Permission denied in /home.10.3/XXXXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 81
pourtant le fichier est en permission 777…
Sur le chargement d’une page non présente dans le cache voici les erreurs :
Warning: sem_get() [function.sem-get]: failed for key 0x152b: Permission denied in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 81
Warning: sem_acquire(): supplied argument is not a valid SysV semaphore resource in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 90
Warning: sem_release(): supplied argument is not a valid SysV semaphore resource in /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 99
Warning: Cannot modify header information – headers already sent by (output started at /home.10.3/XXXX/www/wp-content/plugins/wp-cache/wp-cache-phase2.php:81) in /home.10.3/XXXX/www/wp-includes/pluggable-functions.php on line 272
1er test:
01 befaure.blogspot.com/index.html 124.25 KB 0.52 seconds 0 seconds
02 mathetfleur.blogspot.com/ 67.83 KB 0.34 seconds 0.01 seconds
03 http://www.presse-citron.net/ 42.87 KB 2.51 seconds 0.06 seconds
04 http://www.margaritasanteporcos.com/ 15.39 KB 0.65 seconds 0.04 seconds
05 http://www.loiclemeur.com/france/ 189.03 KB 2.72 seconds 0.01 seconds
06 http://www.2803.com/ 40.71 KB 11.13 seconds 0.27 seconds
2eme test:
01 befaure.blogspot.com/index.html 124.25 KB 0.48 seconds 0 seconds
02 mathetfleur.blogspot.com/ 67.83 KB 0.33 seconds 0 seconds
03 http://www.presse-citron.net/ 42.87 KB 1.91 seconds 0.04 seconds
04 http://www.margaritasanteporcos.com/ 15.39 KB 0.65 seconds 0.04 seconds
05 http://www.loiclemeur.com/france/ 189.03 KB 2.72 seconds 0.01 seconds
06 http://www.2803.com/ 40.71 KB 1.39 seconds 0.03 seconds
En fait, c’est très variable … celui de presse-citron n’est pas mieux en fait …
pareil pour loïc le meur
D’après ce que je lis dans la doc d’installation de WP-Cache, le plug-in semble utiliser les liens symboliques. Il est possible qu’Apache sur les plans mutualisés ne gère pas les liens symboliques par défaut. Aussi, tu peux éventuellement tenter d’éditer le fichier .htaccess à la racine de ton blog pour y insérer la ligne suivante :
Options Indexes FollowSymlinks MultiViews
Par ailleurs, la doc de WP-Cache indique que dans l’écran d’options du plug-in, il y a de la configuration à faire ou du moins des messages d’erreur indiquant les étapes à réaliser pour corriger d’éventuels problèmes…
De même, j’ai vu qu tu avais supprimé certains ajouts (feedbutton par ex.).
C’est une bonne idée, je me suis par exemple rendu compte hier que ce bouton mettait un temps affreusement long à se charger… et bloquer le reste de la page. :(
D’ailleurs, je cherche une solution comparable et viable :)
Coté MySQL : vérifier les index ?
Coté PHP : Pour faire du profiling et trouver les plug-in qui consomment le plus je te conseil deux outils simples et très pratiques : Xdebug et wincachegrid.
Comme tu n’as pas un serveur dédié je te conseil d’installer sous windows (compter 10min) Wamp, tu y installe une copie de ton blog (fichiers via FTP, Base via PHPMyAdmin).
Une fois qu’il tourne sur ta machine, tu install l’extention xdebug de PHP (plein de tutoriaux expliquent comment faire, ça prend 5 min).
Enfin tu install wincachegrid qui est un soft opensource de profiling sous windows (5min too).
Et grâce à cela tu aura le temps exact d’execution de chaque partie de script et tu poura déterminer précisément « qui te coute cher ».
Enfin Coté Apache : peux tu activer la compression Gzip pour alleger encore un peu tes pages ?
Loic j’ai en effet viré feedbutton il mettait 3 plombes à charger! Sinon Kwa et mrboo je vais tester vos pistes, merci encore.
mrboo, la compression des pages dynamiques (donc effectuée de A à Z à chaque page servie) n’est que rarement intéressante. En effet, il faudrait que le processeur du serveur soit plus rapide à compresser que la bande passante allouée du côté serveur et du côté client (c’est le plus lent des deux qui ralentit). Généralement, à moins d’avoir des clients dont la connexion Internet est limitée (modem classique, soit environ 10 % des visiteurs de l’un de mes blogs, notamment), la compression n’accélère pas le chargement des pages (à ma connaissance, les serveurs mutualisés de chez OVH sont connectés à 100 Mbps).
kwa> en effet le gain par GZip ne doit pas être énorme, de toutes façons le problème semble plus lié à l’utilisation importante de plugins externes avec des chargements de tout les cotés vers des API plutot qu’un problème de charge CPU ou de Bande Passante.