Re: réflexion sur la pagination

2016-04-10 13:32 GMT+02:00 Cédric Morin <[email protected]>:

> 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.


> Et pour la question de fil oui peut être se repérer par un numéro d'ordre
> plutôt que par le nombre d'item ? Cela dit c'est déjà codé dans le
> mécanisme pagination : si tu mets debut_truc=@23 ça t'affiche la page qui a
> l'id=23 il suffit donc juste de changer les urls affichées par le modèle
> pagination, ça doit même pouvoir se personnaliser sur seenthis sans modif
> du core (enfin si seenthis était en SPIP 3...)
>
> Cédric
>
> Le 10 avr. 2016 à 11:54, Gilles Vincent <[email protected]> a
> écrit :
>
> 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 ;-)
>
> .Gilles
>
> _______________________________________________
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
>
>