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!).
Citation:
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.
Citation:
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:
Citation:
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"
Citation:
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...)
Citation:
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
