Problèmes avec les pages "Recherche"

Modérateur PHPfrance
Modérateur PHPfrance | 6373 Messages

18 avr. 2006, 13:27

Depuis quelques temps j'ai des pages vides quand je clique sur ces liens :

Voir les nouveaux messages depuis votre dernière visite
Voir ses messages
Voir les messages sans réponses

Pas toujours, et pas tous les liens en même temps. Mais je dirais bien une fois sur 2 facile.
Page vide signifie : une belle page phpBB normale, sauf qu'il n'y a aucun résultat.

Je crois avoir commencé à observer ce phénomène lorsque le code des url automatiques pour les fonctions a été intégré au forum... je ne sais pas si ça peut avoir un lien.

Zeus a les mêmes problèmes, est-ce qu'on est les seuls dans ce cas ?

Modérateur PHPfrance
Modérateur PHPfrance | 7636 Messages

18 avr. 2006, 13:46

Même effet pour moi... mais me sert que rarement de ces liens alors pas remarqué depuis quand :?

/!\ Avant de poster se documenter et rechercher.
Qui ne sait pas rendre un service n'a pas le droit d'en demander.
MaBrute

Administrateur PHPfrance
Administrateur PHPfrance | 3088 Messages

18 avr. 2006, 14:17

Généralement, ce genre d'erreurs est dû à une requête trop longue à s'exécuter. (Apache times out, ou c'est PHP qui meurt à cause du time_limit)

Pourquoi afficher la page une seconde fois fonctionne alors ? simplement parce que la seconde fois les indexes sont déjà en cache (MyISAM's key cache) et les données sont aussi dans un cache, celui de l'OS ou celui du disque dur.

Il faudrait jeter un œil du côté du slow query log pour vérifier ça. Peut-être est-il possible de créer un meilleur index pour ces requêtes.

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

18 avr. 2006, 14:24

Ce n'est pas la 2nd fois qu'on l'affiche que le pb se résoud mais 1 fois sur 2.

Pour moi, je dirais même que, depuis ce matin, j'ai toujours ce problème :?
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer

Modérateur PHPfrance
Modérateur PHPfrance | 6373 Messages

18 avr. 2006, 14:26

Quand je dis une fois sur 2, c'était une moyenne sur le total des essais.

Parceque quand ça arrive, je peux rafraîchir autant de fois que je veux, cliquer et re-cliquer, ça ne change rien.

C'est quand je réessaye quelques minutes après, parfois ça remarche.

Et c'est étonnant que ça soit un problème de requête trop longue quand même car ça ne m'avait jamais fait ça avant, et les résultats ne sont pas si important je pense.

Bon après je ne fais que supposer...

Administrateur PHPfrance
Administrateur PHPfrance | 3088 Messages

18 avr. 2006, 16:10

Et c'est étonnant que ça soit un problème de requête trop longue quand même car ça ne m'avait jamais fait ça avant, et les résultats ne sont pas si important je pense
Si les requêtes de ces pages font un full scan, c'est normal que ce problème apparaisse de plus en plus souvent (à mesure que la table des posts/topics grandit). La vérité se trouve dans le slow query log...

Modérateur PHPfrance
Modérateur PHPfrance | 6373 Messages

18 avr. 2006, 16:19

Si les requêtes de ces pages font un full scan, c'est normal que ce problème apparaisse de plus en plus souvent (à mesure que la table des posts/topics grandit)
C'est vrai tu as raison, enfin j'étais étonné car 'cest la première fois que je vois ça tous forums confondus

Donc on attendra de savoir ce qu'il en est dans les logs alors...

Merci de t'être penché sur le sujet, j'utilise énormément ces liens et c'est un petit agaçant à la longue... :)

Administrateur PHPfrance
Administrateur PHPfrance | 3088 Messages

18 avr. 2006, 16:56

Je viens de regarder un peu mieux les requêtes en question et... j'ai bien peur qu'on ne puisse pas faire grand-chose. On pourrait accélérer la requête "unanswered" avec un index spécial comme:

Code : Tout sélectionner

ALTER TABLE phpbb_topics ADD INDEX unanswered (topic_moved_id, topic_replies, forum_id)
mais la requête n'est pas particulièrement lente (~15ms). Les "egosearch" et "newposts" sont un peu plus délicats. Là non plus les requêtes ne sont pas particulièrement lentes mais elles peuvent être très très longues, et là je parle de leur syntaxe. Elles utilisent toutes deux une ou plusieurs requêtes de type:

Code : Tout sélectionner

SELECT post_id FROM phpbb_posts WHERE poster_id = 123; SELECT ... FROM ... WHERE post_id IN (1, 2, 3, 4, 5, 6, ...)
Donc plus la première requête renvoit de post_ids et plus la seconde requête est longue. Et j'ai souvent remarqué que MySQL n'aimait pas trop les trop longues requêtes.

Ça explique aussi pourquoi je n'ai jamais souffert de cette fameuse page blanche, parce que je visite souvent les forums donc il n'y a que peu de nouveaux posts, et je n'ai pas beaucoup de posts à mon actif donc la requête de l'egosearch est plus courte. Demandez un peu à Cyrano de faire un egosearch pour voir :lol:

On pourrait essayer de changer la seconde requête pour utiliser une sous-requête et/ou une table dérivée. Ou même une table temporaire en fait. J'essaierai d'y réfléchir lorsque j'aurai quelques minutes ;)

Modérateur PHPfrance
Modérateur PHPfrance | 6373 Messages

18 avr. 2006, 17:05

Perso j'utilise uniquement "mes messages" (beaucoup) et "messages sans réponse" (un peu)

Et une simple limitation sur le nombre de résultats (prendre uniquement mes 100 derniers messages par ex) ?

ça ne gênerait pas trop puisqu'on surveille surtout les derniers messages postés, et ça ferait gagner du temps non ?

Avec la possibilité de vraiment (tenter de) récupérer tous les messages si on souhaite en retrouver un vieux en cliquant sur un autre lien :)

Administrateur PHPfrance
Administrateur PHPfrance | 1275 Messages

19 avr. 2006, 12:26

Il faudrait jeter un œil du côté du slow query log pour vérifier ça. Peut-être est-il possible de créer un meilleur index pour ces requêtes.
Le slow query log des 7 derniers jours est vide. Il y a eu des slow queries qu'aujourd'hui il y a 15 minutes, j'ai redemarré MySQL pour régler le problème.