Bonjour,

je développe un site sous Symfony2 et grâce à sa barre de profiler intégrée, je peux voir que j'ai jusqu'à 14 requêtes sur certaines pages.

Je lis un peu partout qu'au dessus de 5 requêtes c'est quasi-inacceptable et ça me fait un peu peur.
J'ai déjà utilisé des jointures pour éviter des requêtes supplémentaires, mais par exemple, rien que sur la page d'accueil j'ai:

1. une requête pour récupérer le texte d'accueil
2. une requête pour récupérer le nombre de notification de l'utilisateur connecté
3. une requête pour récupérer les 4 derniers utilisateurs inscrits
4. je limite cette requête avec le Paginator ( = 1 requête supplémentaire)
5. une requête pour récupérer les 4 derniers posts
6. je limite cette requête avec le Paginator ( = 1 requête supplémentaire)
7. une requête pour récupérer les 10 tags les plus utilisés
8. je limite cette requête avec le Paginator ( = 1 requête supplémentaire)
9. une requête automatiquement faite par Symfony2 pour récupérer l'utilisateur connecté en DB

Donc, un total de 9 requêtes SQL, rien que sur la page d'accueil
Ces données n'ont rien à voir les une avec les autres donc je ne vois pas comment je pourrai les récupérer en moins de requêtes...

Mes questions sont donc les suivantes:

• Est-ce qu'il est vraiment mal d'avoir jusqu'à 14 requêtes par pages? Le profiler indique que doctrine prend 43ms pour exécuter ces requêtes, en mode Dev évidemment.
• Comment pourrais-je récupérer des données à priori pas liées entre elles en effectuant moins de requêtes?
• Quelles sont les vraies conséquences d'un trop plein de requêtes SQL? Les pages seront inaccessibles?
• Dans le profiler, le logo de Doctrine devient jaune (warning) à partir de 50 requêtes... C'est un indicateur valable ou c'est une valeur au pif?

Merci d'avance pour vos réponses

Salut,

Y'a pas vraiment de constante magique sur le nombre de requêtes limites. Forcément, moins tu en as et plus rapide ce sera, mais là 14 requêtes ç'a n'a rien de dramatique.
En l'occurrence 43ms c'est pas si énorme que ça, et c'est ce chiffre l'essentiel, parce que tu pourrais très bien en faire le triple avec une requête mal faite.

Avant de penser à diminuer le nombre, regarde si tes requêtes sont optimisées. Vérifie tes index en base de donnée, tes contraintes relationnelles, et évite à tout pris les requêtes dites "N+1" qui font perdre un temps fou et sont assez fréquentes.
Après ça, et si les performances te semblent un problème ou que tu as un fort traffic, tu peux regarder du côté des systèmes de cache de bases de données et/ou d'externalisation, comme Solr, ElasticSearch ou Redis.
Selon ton SGBD, l'utilisation de vues pour mettre en cache localement les requêtes peut ou peut ne pas être une bonne idée. Si ta base est correctement indexée et optimisée l'utilisation de vues compliquera plus qu'autre chose pour pas énormément de bénéfices, mais ça peut être intéressant à regarder.

Ah et, bien sûr, le cache côté serveur est toujours une bonne idée, et facile à mettre en place.

Merci Caletlog pour ta réponse bien détaillée et tes conseils.
J'ai évité les requêtes N+1 (je ne savais pas qu'on les appelaient comme ça) grâces aux jointures.

Je me renseigne sur le reste et en priorité sur le cache côté serveur.

Salut,

Il y à des applis avec plus de 50 requêtes par pages...
Par ailleurs il y à des serveurs dédiés avec tellement de RAM que tu peu avoir toute ta base en RAM et donc avoir des temps de réponse très bons même avec des tonnes des requêtes. La ou ça peu coincer s'est si tu es sur un mutualisé avec un serveur sql qui rame.
D'après mon expérience tu peu avoir 50 requêtes par page et pas avoir de probleme de perf, et par contre avoir des problèmes de perfs avec une seule requête mal foutue ou qui rame à cause par exemple d'index manquants.

Donc du coup il faut pas paniquer parce que tu as beaucoup de requêtes SQL. Ce qu'il faut voir c'est d'avoir tes requêtes optimisées sur une base optimisée, et si possible sur un serveur optimisé (donc beaucoup de RAM attribuée au SGBD par exemple).