Discussion :

[MNoob]

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

[arnooo999]

Bonjour,


On ne peut pas dire qu'il y ait un nombre de requete à ne surtout pas franchir.
Disons qu'il sera généralement plus "rentable" d'augmenter les ressources du serveur que de payer un développeur pour améliorer les performances.


L'important me semble être de monitorer les requetes lentes en prod pour détecter les anomalies
ex avec mysql : https://dev.mysql.com/doc/refman/5.1...query-log.html

De mon expérience, il suffit d'une requete sur une table mal optimisé (gros volume + index manquant notamment) pour ralentir ton appli (bien plus qu'une requete HTTP avec 14 requetes SQL!).

Le profiler indique que doctrine prend 43ms pour exécuter ces requêtes, en mode Dev évidemment.

Pour infos il s'agit de la durée d'execution par mysql, le fait d'être en dev ou en prod n'affecte pas ce résultat, c'est donc un indicateur valable.
A toi d'analyser la durée d’exécution de chaque requete pour détecter des anomalies.
fait des test dans phpmyadmin pour voir si tu peux en améliorer certaines.

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?
Je dirais une valeur au pif!

Je n'avais pas remarqué, mais cela est sans doute destiné à alerter sur un abus de lazy loading (requete executé pour chaque item d'une collection)
c'est surtout cela qu'il faut éviter car là le nombre de requetes va varier selon les pages.

Voici quelques idées d'optimisation:

une requête pour récupérer le nombre de notification de l'utilisateur connecté

avec un SELECT COUNT?
celle-ci pourrait être couplé avec la requete de récupération de l'utilisateur faite par symfony.
Il faut passer par un UserProvider perso faire un "SELECT u, COUNT(u.messages) FROM User u WHERE u.id=:id"

une requête pour récupérer les 4 derniers utilisateurs inscrits
je limite cette requête avec le Paginator ( = 1 requête supplémentaire)

je comprends pas l'utilisation du Paginator, ça doit pouvoir se faire avec un max result et un orderby.
par defaut le Paginator doctrine crée des requetes lourdes (mais ça peut se simplifier...)

une requête pour récupérer les 10 tags les plus utilisés
je limite cette requête avec le Paginator ( = 1 requête supplémentaire)

idem pour le paginator
ça ne semble pas être une requete dont les résultats varient beaucoup, donc un bon candidat à l'utilisation du cache de resultat doctrine
http://doctrine-orm.readthedocs.org/...l#result-cache
en appelant la methode setResultCacheLifetime(3600) sur ton objet Query, les mêmes resultats seront servis durant une heure sans requetes SQL supplémentaire quelque soit le nombre de requete HTTP.


Pour rappel le profiler Symfony a un onglet Timeline qui te donnera des infos pour optimiser le chargement des pages.


Enfin pour gérer la montée en charge de ton appli, il faut penser plus globalement à mettre en cache l'ensemble des résultats.
Le cache http est ton ami:
http://symfony.com/fr/doc/current/book/http_cache.html

[MNoob]

Bonjour,

merci pour toutes ces informations et ces conseils.
Je vais voir tout ça, ça m'aide énormément.

je comprends pas l'utilisation du Paginator, ça doit pouvoir se faire avec un max result et un orderby.
par defaut le Paginator doctrine crée des requetes lourdes (mais ça peut se simplifier...)

J'ai oublié de le préciser mais mes requêtes contiennent de nombreuses jointures (tags de l’utilisateur, nombre de contacts, ...) et si je ne passe pas par le Paginator, j'obtiens moins de résultats que prévu