Mon site sous symfony est très long à charger

Version imprimable

28/04/2021, 21h28
MetaProjet

5 pièce(s) jointe(s)

Mon site sous symfony est très long à charger

Bonjour à tous

Voilà mon site web sous symfony est très lent à charger (hébergement OVH mutualisé). J'ai essayé sur différents ordinateurs et différentes connections. Quand je continue la navigation, les temps de chargement deviennent plus court. Mais quand je me connecte à son adresse, le chargement est très long !

J'ai effectué des copies d'écrans d'éléments qui pourraient être utiles, mais je n'arrive pas à les interpréter pour me sortir du problème :

Pièce jointe 596776

Pièce jointe 596777

Pièce jointe 596778

Pièce jointe 596779

Pièce jointe 596780

Si quelqu'un à une idée je le remercie d'avance

Laurent
29/04/2021, 11h36
armel18
bonjour,

la toolbar montre qu'il y a 19 requêtes SQL qui s'exécutent en 23.71ms (19 in 23.71ms ). Et ces 19 requêtes sont susceptibles d'évoluer à mesure que les données de la BD augmentent.
19 requêtes pour une seule page c'est beaucoup.
Tu as probablement des requêtes SQL supplémentaires générées, lesquelles requêtes sont liées au mode de chargement de tes associations en l’occurrence le mode fetch="LAZY".

Sur la toolbar, clique sur 19 in 23.71ms , ensuite sur Group similar statements, tu verras les requêtes SQL s'afficher ainsi que le nombre de fois où elles sont appelées( COUNT ). Si le COUNT de chaque requête est supérieur à 1 alors tu as un problème de LAZY loading et dans ce cas tu peux changer le mode de chargement de tes associations en EAGER ce qui veut dire récupère moi l'entité que je veux afficher ainsi que l'entité jointe en faisant qu'une seule requête avec jointure(voir l'exemple)
Code:

1 2 3 4 5 6 //Article.php /** * @ORM\ManyToOne(targetEntity=Category::class, inversedBy="articles", fetch="EAGER") */ private $category;
Mais tu peux aussi faire des requêtes DQL ou QueryBuilder à place de faire find, findBy ... avec DQL ou QueryBuilder, le mode de chargement n'a plus aucune importance car ce n'est plus l'ORM qui génère les requêtes.

Après si entre 2 appels, ta page ne change pas souvent il est possible de mettre en cache les données issues de la BD. Ainsi tu supprimes les appels inutiles à la BD. Mais le cache n'est bénéfique que si le code est déjà optimisé.
29/04/2021, 20h52
MetaProjet

Effectivement j'ai certaines requêtes qui sont effectuées plus de cinq fois. Je vais donc me pencher sur le tutoriel que tu m'as indiqué.

Parfois le site se charge néanmoins à une vitesse raisonnable, je ne comprends pas l'irrégularité.

Mais dans tous les cas un très grand merci pour ton message détaillé et pédagogique.
03/05/2021, 10h18
samche2000

Bonjour,

Serait-il possible d'avoir un retour après optimisation des requêtes SQL ?

J'ai dû mal à comprendre quels mécanismes permettent de réduire le chargement d'une page de 33 secondes en optimisant une fonctionnalité qui prend 23 ms.
04/05/2021, 13h14
grunk

Commence par désactiver xdebug qui doit faire bien du mal en terme de performance.

Se concentrer sur les requête sql n'a pas de sens pour le moment puisque le temps qu'elle prennent est négligeable.

Si tu peux essai d'utiliser une IP pour l'adresse de ta base de données pour éviter un lookup dns qui parfois peut être longue (genre 127.0.0.1 au lieu de localhost).

Est ce que tu as configuré tous les caches nécessaire ? Particulièrement sur un hébéergement mutualisé c'est important de minimiser autant que possible les accès disques et cpu
28/05/2021, 18h18
MetaProjet

Bonjour à tous, merci à Samche200 et grunk pour votre follow-up, désolé pour le délai je n'avais connaissance de vos messages.

Je ne suis pas un codeur expérimenté alors mes commentaires sont à prendre avec des pincettes.

Citation:

Envoyé par samche2000

Serait-il possible d'avoir un retour après optimisation des requêtes SQL ?

Il semblerait que l'optimisation des requêtes sql n'apporte pas de gain significatif en terme de temps de chargement (toutefois merci à armel18 de m'avoir sensibilisé à ce problème qui s'empirerait à mesure d'insertions dans la db).

Citation:

Envoyé par grunk

Commence par désactiver xdebug qui doit faire bien du mal en terme de performance.

Si j'en crois la Debug Toolbar du remote, xdebug est désactivé (toutes les copies d'écrans font référence au remote).

Citation:

Envoyé par grunk

Si tu peux essai d'utiliser une IP pour l'adresse de ta base de données pour éviter un lookup dns qui parfois peut être longue (genre 127.0.0.1 au lieu de localhost).

Sur le remote l'adresse de ma base de donnée suis le pattern suivant : p*a550.mysql.db:3306 (correspondrait-il à ta recommandation ?)

Citation:

Envoyé par grunk

Est ce que tu as configuré tous les caches nécessaire ? Particulièrement sur un hébéergement mutualisé c'est important de minimiser autant que possible les accès disques et cpu

Non je n'ai aucune compétence dans ce domaine, si tu as un tuto ou une doc à me conseiller, je suis très motivé pour essayer.

Sur ce sujet il y a une question qui me taraude depuis plusieurs semaines. Sur le remote, dès que je lance cache:clear, j'obtiens ! [NOTE] For better performances, you should move the cache and log directories to a non-shared folder of the VM. Malgré des recherches je ne comprends pas ce que signifie "non-shared folder of the VM". Dossier non partagé du gestionnaire virtuel ??? Si quelqu'un peu m'expliquer en termes simples ce que cela signifie :-) ?

Merci à tous

Laurent

ps : voici l'adresse du dépôt Github : https://github.com/LoloForThePOP/meta-project
08/06/2021, 11h26
samche2000

Déplacer le cache symfony sur un ramdisk peut t'aider à gagner en lecture/écriture du cache. Il sera vidé à chaque redémarrage du serveur mais est-ce vraiment un problème ?

Pour l'adresse de la base de données, Grunk te préconise d'utiliser l'adresse IP du serveur plutôt que son DNS. Un bon moyen pour trouver, tu ping p*a550.mysql.db, il te donnera l'adresse IP du genre w.x.y.z. Puis dans ton application, tu remplaces p*a550.mysql.db:3306 par w.x.y.z:3306. Bien sûr, cela n'est valable que si il n'y a pas de Round Robin DNS sur ce nom.
23/06/2021, 15h56
MetaProjet

Bonjour à tous

Disparition de ralentissements depuis que j'ai changé le répertoire de cache de mon site (et disparition du message d'avertissement "you should move the cache and log directories to a non shared folder..."). Pour ceux qui souhaitent connaître la procédure simple à réaliser, voici deux liens complémentaires utiles :

- https://community.ovh.com/t/resolu-s...rgement/2503/5
- https://stackoverflow.com/questions/...714915#8714915

À noter qu'avec des versions plus récentes de symfony, c'est kernel.php qu'il faut modifier (et non pas appkernel.php).

Citation:

Envoyé par grunk

Si tu peux essai d'utiliser une IP pour l'adresse de ta base de données pour éviter un lookup dns qui parfois peut être longue (genre 127.0.0.1 au lieu de localhost).

J'ai l'impression que je n'ai pas cette possibilité sur un ovh mutualisé : "veuillez utiliser le nom d'hôte pour vous connecter à votre instance, l'adresse ip pouvant évoluer avec le temps" (ndr : d'ailleurs je ne parviens pas à ping le nom d'hôte de ma db, on me renvois une erreur).

Merci à tous ceux qui m'ont apporté des idées pour remédier au problème :-)
01/10/2021, 10h10
MetaProjet

EDIT :

Malheureusement, je suis forcé de constater que malgré la mesure prise dans le post précédent (peut-être utile malgré tout), le ralentissement majeur au chargement du site n'a pas disparu. Je clos ici mes investigations.