[spip-dev] réflexion sur la pagination

Dev
1

Salut la liste,

le mécanisme de pagination automatique dans SPIP est cool,… mais loin d’être optimal.

Sur forum.spip.net, il génère des requêtes qui peuvent prendre plus de 2 secondes !

Voici le type de boucle générée :
http://spip.pastebin.fr/46321

La requête parcourt prêt de 9 millions de lignes via des tables temporaires sans passer par un index.
Voici le résultat du EXPLAIN :
http://spip.pastebin.fr/46322

Le problème est lié à plusieurs éléments :

  • Une combinaison LIMIT + ORDER BY

  • Un LIMIT important dans des boucles en UNION

  • Un tri sur un champ calculé

Pour résoudre cela, je vois plusieurs approches :

  • revoir la navigation pour avoir moins d’accès directs (voire enlever les accès directs et utiliser un chargement progressif)

  • mettre en cache des résultats intermédiaires avant de les trier (pour pouvoir les utiliser à plusieurs niveaux de pagination)

Je n’invente rien, je m’inspire d’exposés trouvés sur slideshare :
http://fr.slideshare.net/MarkusWinand/backend-to-frontend-when-database-optimization-affects-the-full-stack

Est-ce que ça vous semble pertinent de travailler sur un tel chantier ?

Perso, avec un accès aux forums, j’ai un bel espace de travail :wink:

.Gilles

2

J’ajoute un autre problème : lorsqu’on passe d’une page à l’autre, il est possible que les messages aient changé (ajout de nouveaux messages dans la base), ce qui provoque un décalage pas très heureux. On le constate en permanence sur seenthis.

Une piste de solution pour cela pourrait être de se baser non pas sur le nombre de messages qu’on ignore, mais sur un marqueur d’ordre (id_x ou date).

3

Fil a écrit le 10/04/2016 12:00 :

J'ajoute un autre problème : lorsqu'on passe d'une page à l'autre, il
est possible que les messages aient changé (ajout de nouveaux messages
dans la base), ce qui provoque un décalage pas très heureux. On le
constate en permanence sur seenthis.

Une piste de solution pour cela pourrait être de se baser non pas sur le
nombre de messages qu'on ignore, mais sur un marqueur d'ordre (id_x ou
date).

Un peu de littérature sur le sujet :

4

Je ne comprends pas pourquoi tu parles de pagination dans le sujet et tu fournis en exemple une requête de recherche non paginée…
Ici c’est une requête sql de fulltext qui est lente.

5

Je ne comprends pas pourquoi tu parles de pagination dans le sujet et tu
fournis en exemple une requête de recherche non paginée...

Effectivement, c'est dans le plugin Fulltext.
C'est en cherchant les lenteurs liées à l'origine de cette combinaison
ORDER BY + LIMIT, je suis tombé essentiellement sur des exemples de
pagination. Et je ne voyais pas l'intérêt, en dehors de ce type de
situation, de limiter à 500.
Mais ta réponse m'a poussé à regarder dans le plugin Fulltext.
C'est lui qui contient effectivement une borne à 500 fixée par la constance
_FULLTEXT_MAX_RESULTS
Donc s'il y a un truc à voir, c'est pour ce plugin et pas pour le core.
Sorry

Ici c'est une requête sql de fulltext qui est lente.
Avec la pagination il n'y a pas de clause LIMIT dans les requêtes, et la
pagination ne génère pas non plus de JOIN ni et UNION.

Oui, pour le Union, je me suis planté avec une autre requête.
Mais le JOIN, c'est fulltext. Curieux d'ailleurs qu'il ordonne les 100
éléments de la jointure

Cela dit je penche de plus en plus souvent pour une navigation de type
page suivante/page précédente sur les sites public, cela limite un peu les
cas stressants - mais guère, les bots sont infatigables sur le sujet.

De grâce, jamais jamais jamais de ce fucking chargement infini
automatique...

Pour revenir au point de départ il fait mettre une recherche par sphinx
peut être ?

Je vais mettre Sphinx sur forum.spip.net, ce sera plus efficace je suis
d'accord.