Problèmes avec les pages "Recherche"

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Problèmes avec les pages "Recherche"

par Damien » 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.

par ouckileou » 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 :)

par Hubert Roksor » 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 ;)

par ouckileou » 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... :)

par Hubert Roksor » 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...

par ouckileou » 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...

par zeus » 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 :?

par Hubert Roksor » 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.

par Truc » 18 avr. 2006, 13:46

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

Problèmes avec les pages "Recherche"

par ouckileou » 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 ?