Chargement très long (Créer un compte)

Le site c’est : http://avec-mes-enfants.fr/

J’ai refait des tests en enlevant les pubs mais ça améliore juste le temps du chargement total de la page, la première requête reste relativement longue (en moyenne 15s après plusieurs tests sous Firebug).

Les permaliens sont en mode Structure personnalisée : /%postname%/

J’aimerais tester en désactivant des plugins mais je sais pas si cela aura des conséquences à long terme notamment pour les plugins All in One SEO Pack et Redirection.

Une autre question en rapport, concernant le plugin WP Super Cache, je peux l’activer et le désactiver comme ça à la volée pour un test ?

@pedronimo : en fait j’étais tombé sur ton site en premier, en faisant une recherche Google à propos de mon problème. C’est d’ailleurs dessus que j’ai trouvé le lien vers la discussion du forum d’OVH.

La requête pour récupérer le code html de base (selon Firebug) met grave du temps et récupérer 5Ko en 15s, je pense que ça doit être un problème lié à WordPress. Si je désactive le cache avec la Web Developer Toolbar, le temps est toujours le même pour cette requête.
Surtout que pour récupérer des fichiers plus gros il met 20 fois moins de temps.

Quelqu’un sait si je peux désactiver les plugins All in One SEO Pack et Redirection à l’arrache, sans faire une connerie ? Est-ce que ça ne va pas supprimer dans la base de données, les infos pour chaque page voir celle du site (ou cela se fait-il uniquement en cas de suppression) ?

@JayLBR : en fait les autres plugins que je n’avais pas cité sont désactivés sauf WP Super Cache qui a été activé entre temps (voir plus bas).

Voilà récemment il y avait eu une amélioration, la première requête ne s’effectuant qu’en quelque centaines de ms et le temps total étant relativement rapide.
Mais je pense que c’était plus du à l’activation du plugin WP Super Cache (j’avais fait des tests avec mais sans doute mal réalisé) par la personne qui s’occupait du site avant moi, dont on a fait appel (pas moi) pour résoudre le problème.
Mais récemment il y a encore des ralentissements et de manière aléatoire.

Avant de retourner sur ce topic, j’ai fait un test, et le premier essai a mis pas mal de temps (plus de 15s), tandis qu’au second rafraichissement j’avais un chargement plus correct (quelques secondes), alors je me suis posé la question sur le cache. (Ce qui me parait bizarre aussi c’est qu’hier vers 3h du matin, j’ai fait un test, le chargement était long j’ai rafraichi plusieurs fois mais ça n’a rien changé).

Je décide de refaire des tests :
Je vide le cache navigateur, je charge :
-> 1ère requête en 1,2s et temps total de 21,8s
je rafraichis
-> 1ère requête en 1,8s et temps total de 4,03s

Je désactive WP Super Cache et le code dans le .htaccess (on sait jamais) :
Je vide le cache navigateur, je charge :
-> 1ère requête en 1,39s et temps total de 19.9s
je rafraichis
-> 1ère requête en 1,86s et temps total de 4,73s

Je commente les lignes

define(‘WP_CACHE’, true); //Added by WP-Cache Manager

du fichier wp-config.php :
Je vide le cache navigateur, je charge :
-> 1ère requête en 14,1s et temps total de 37,98s
je raffraichis
-> 1ère requête en 14,63s et temps total de 20,15s

J’ai rajouté le bout de code de JayLBR :
2661 requêtes. 12,298 secondes

Je remets les lignes du fichier wp-config.php mais là malheureusement il a gardé dans son cache une page où le code d’affichage des requêtes n’apparaît pas.
Donc je cherche cette page dans le dossier wp-content/cache, je la supprime, je recharge, là ça prend un bon bout de temps (comme d’hab 13s pour la 1ére requête).
Je rafraichis et tout redeviens rapide, mais bon il doit se caler sur une autre page en cache du coup le nombres de requêtes et le temps sont les mêmes à chaque fois.

2661 requêtes ça me parait un bon paquet quand même, pauvre base de donnée ! (idem pour le temps)

Bref tout ça me dis juste que le problème se résout partiellement grâce au cache (d’ailleurs c’est un plugin ou c’est le cache de WordPress lui-même ? Qu’est-ce que WP-Cache Manager car je ne le vois pas dans les extensions ?)

En plus de ça, un problème est apparu sur le forum en fluxBB (bon je sais que ça n’a rien à voir avec WordPress), un problème d’accent, avec tout ça je me demande si la mise à jour de la base de donnée n’aurait pas foutu aussi sont bordel dans l’interclassement des tables du forum, car dans l’administration de celui-ci, on ne peut quasiment rien changer à la configuration et l’auteur du blog n’a aucune connaissance en base de donnée (ne serait-ce que pour accéder à phpmyadmin par exemple).

Je vais faire un test dans la nuit en désactivant les plugins un par un (voir tous en même temps) et en voyant le nombre de requêtes sans cache.

Edit : en regardant sur le net, en fait 2600 requêtes, si ce sont bien des requêtes sur la base de donnée, c’est tout simplement ENORME 😉 surtout quand je vois des sites qui proposent d’améliorer le temps d’exécution en supprimant 30 requêtes sur le template…
http://batou.e3b.org/wordpress/index.php/2009/05/14/reduire-le-nombre-de-requetes-sous-wordpress-erreur-sql-max_questions-resource

Bon petite mise à jour depuis le temps.
En fait OVH a bloqué l’accès au site, en considérant que le site est en etat de « hacké ».
Ils disent qu’il y a trop de requêtes (c’est pas nouveau, il pouvait prévenir avant) et que ça fait ramer le CPU.
Bon bref j’ai remis le site en actif, mais je pense que la base de donnée n’est pas encore rétabli.

Ils m’ont dit d’aller voir le log sur OVH.
Et là je vois ça pour le mois d’avril (le début des problèmes) :

Name Last modified Size
26-04-2009.log.gz 27-Apr-2009 02:43 303
27-04-2009.log.gz 28-Apr-2009 02:42 769
28-04-2009.log.gz 29-Apr-2009 02:55 522
29-04-2009.log.gz 30-Apr-2009 01:02 9.7M
30-04-2009.log.gz 01-May-2009 01:12 61M

Passer d’un fichier de quelques lignes et de 500 octets à un fichier de 60 000 000 d’octets et comprésser en plus !!

Sachant qu’un mail a été envoyé le 27-Apr-2009 à 22h, pour annoncer qu’on devait changer la taille la base et considérant que les erreurs se sont multipliés le jour où le changement a été validé par le propriétaire du site, je commence à avoir de sérieux doute.

Surtout qu’aucun plugin n’avait été installé à cette période, et aucune modification n’avait été faite sur un fichier quelconque de wordpress (si mes souvenirs sont bons, je peux toujours avoir modifier le template tout au plus).

En tentant d’ouvrir un des fichiers logs de 60Mo (comprésser donc 500Mo à l’arrivée, je vous raconte pas avec 512Mo de Ram la réactivité du pc :fire: et ma légendaire patience 😇) j’ai pu voir une erreur qui apparaissait souvent (j’ai corrigé volontairement des accents pour plus de lisibilité) :

Erreur de la base de données WordPress Got a packet bigger than ‘max_allowed_packet’ bytes pour la requête INSERT INTO wp_options (option_name, option_value, autoload) VALUES (‘rewrite_rules’, ‘………

En tapant juste sur google wordpress VALUES (‘rewrite_rules’ :

Un topic de forum (bon ok c’est pour wordpress µ :rolleyes:) qui parle de corruption de la base de donnée :
http://mu.wordpress.org/forums/topic/4953

Un autre topic sur wordpress :
« Since a few weeks a wordpress site of mine has gotten very slow. On inspection I found out it runs about 2400 database queries for each page. »
http://wordpress.org/support/topic/236199