Re: réflexion sur la pagination
Cédric Morin <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[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... 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. 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 ? 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