Discussion :

[MetaProjet]

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 :












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

Laurent

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é.

[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.

[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.

[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

[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.

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).

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).

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 ?)

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