-
Rien du tout.
Relit ce que j'ai écrit plus haut, IL NE REQUETE QUE LES X RESULTATS QUE TU DEMANDE DANS LE PAGER : SOIT 10 dans ce que tu as écrit sur le forum et 20 dans ton code car apparemment il te retourne 20 résultats.
Les perfs si tu te base sur ton pc de dev c'est normale qu'elles soient médiocre sauf si tu as a un pc de type core i7 16Go et sous linux.
Après je ne connais pas ton projet, mais par exemple j'ai un projet qui en dev (Core i7 6Go avec linux) affiche la page d'accueil en 2secondes alors qu'en prod il s'exécute en 1 seconde. (Oui le projet est pas tip top actuellement, problème d'indexation, trop de requête généré sur la bdd, et aussi trop d'objet instanciés pour rien.)
Il faut prendre en compte que en dev tu as toutes les erreurs, les log's, pas de cache etc...
-
Je reprends :mrgreen:
Mon problème est au niveau de la performance. J'est l'impression que retourner les 5000 enregistrements de la base affecte l'affichage la page.
Est-ce que le fait de ne retourner que les 1000 derniers enregistrements accelère l'affichage ou pas?
-
Merci kenny.kev, je viens de voir ta réponse.
Finalement ça ne sert rien de faire un LIMIT, la requête ne se fait que sur le second paramètre du constructeur de sfDoctrinePager().
-
Conclusion...
Non limiter aux 1000 dernières lignes n'améliorera jamais tes résultats.
Pour compter le nombre de pages, Symfony fait un compte sur ta requête, donc pour SQL faire un compte de 1000 ou 5000 il n'y a presque pas de différence, puis le pager de symfony utilise un LIMIT X,Y dans la requête pour n'avoir que les résultats affichés sur la page, donc de 20 à 30 par exemple si t'en a 10 par pages...
Globalement, tu peux laisser tous les liens vers tes 500 pages, après si les données ne doivent pas être visibles il suffit de bloquer les pages >100 dans l'indexAction tout simplement avec un if($page>100) { $page = 0; } par exemple (avec $page = $request->getparameter('page'); je crois )
