ralentissement fiche produit en bo

[kidoshop]

depuis quelques temps j ai un soucis quand je vais sur une page produit pour changer quelque chose comme la quantité par exemple le bouton enregistrement et enregistrement et rester mouline avant de pouvoir validé

a savoir que je suis en 1.6 .1.6 que je n ai pas installer de nouveau module ni fait de mise a jours

j ai meme essayer de désactiver l un apres l autre les modules et cela n a rien changer

j ai contacter mon hébergeur et aucun probleme de se coté la et meme la navigation est tres fluide 

avez vous une idée ?

 

[Eolia]

Ouvrez votre console navigateur (F12 ou bouton droit "inspecter l'élément") et regardez ce qui prend du temps dans l'onglet réseau/network et sous onglet "xhr"

[kidoshop]

apparement j ai ca mais je suis pas expert 

[wepresta]

8 hours ago, kidoshop said:

apparement j ai ca mais je suis pas expert 

Problème d'intégration de Jquery on dirait 

[kidoshop]

comment puis je reparer cela ? merci

 

[wepresta]

4 minutes ago, kidoshop said:

comment puis je reparer cela ? merci

 

Avez-vous installé ou mis à jour un module récemment, ou apporté des modifications à votre code ?

[kidoshop]

5 minutes ago, wepresta said:

Avez-vous installé ou mis à jour un module récemment, ou apporté des modifications à votre code ?

non c est bien pour cela que je ne comprend pas 

[Zohaib-fk]

Bonjour,

Cela m'est également arrivé dans le passé parce que j'ai ouvert le back-office dans plusieurs onglets ou applications exécutées en arrière-plan ou sur un serveur occupé parce que j'ai partagé un hébergement Web avec moins de RAM et de CPU.

Capture d'écran ci-jointe.

Essayez d'ouvrir le back-office dans différents navigateurs comme Microsoft Edge ou Chrome ou Safari. Videz le cache ou autre étape de dépannage.

Le lien ci-dessous propose une solution pour désactiver l'idée de désactivation du module psconnect.

https://www.presta-addons-modules.com/en/blog/228_Prestashop-slow-back-office-.html

 

[Eolia]

Vous avez des modules hookés dans le backofficeheader qui chargent leur js sans contrôler que jQuery est déjà chargé.

Vous saurez quels modules sont responsables en passant la souris sur le nom du script

[kidoshop]

8 hours ago, Eolia said:

Vous avez des modules hookés dans le backofficeheader qui chargent leur js sans contrôler que jQuery est déjà chargé.

Vous saurez quels modules sont responsables en passant la souris sur le nom du script

merci pour tout j ai trouvé le module qui me faisait cela malgres qu'il était désactiver 

[Zohaib-fk]

Bienvenu. Ça fait du bien de savoir que le problème est résolu.

Vous pouvez essayer la commande SQL ci-dessous pour accélérer l'exécution de l'instance et réduire la charge et la taille de la base de données. Mais effectuez une sauvegarde avant d'exécuter ces requêtes SQL.

TRUNCATE TABLE ps_connections ;
TRUNCATE TABLE ps_connections_source ;
TRUNCATE TABLE ps_connections_page ;
TRUNCATE TABLE ps_guest ;
TRUNCATE TABLEps_log ;
TRUNCATE TABLE ps_referrer ;
TRUNCATE TABLE ps_referrer_shop ;
TRUNCATE TABLE ps_referrer_cache ;
TRUNCATE TABLE ps_pagenotfound;
TRUNCATE TABLE ps_mail ;
TRUNCATE TABLE ps_statssearch;
TRUNCATE TABLE ps_smarty_cache;
TRUNCATE TABLE ps_smarty_last_flush;
TRUNCATE TABLE ps_smarty_lazy_cache;

[Eolia]

il y a 7 minutes, Zohaib-fk a dit :

Bienvenu. Ça fait du bien de savoir que le problème est résolu.

Vous pouvez essayer la commande SQL ci-dessous pour accélérer l'exécution de l'instance et réduire la charge et la taille de la base de données. Mais effectuez une sauvegarde avant d'exécuter ces requêtes SQL.

TRUNCATE TABLE ps_connections ;
TRUNCATE TABLE ps_connections_source ;
TRUNCATE TABLE ps_connections_page ;
TRUNCATE TABLE ps_guest ;
TRUNCATE TABLEps_log ;
TRUNCATE TABLE ps_referrer ;
TRUNCATE TABLE ps_referrer_shop ;
TRUNCATE TABLE ps_referrer_cache ;
TRUNCATE TABLE ps_pagenotfound;
TRUNCATE TABLE ps_mail ;
TRUNCATE TABLE ps_statssearch;
TRUNCATE TABLE ps_smarty_cache;
TRUNCATE TABLE ps_smarty_last_flush;
TRUNCATE TABLE ps_smarty_lazy_cache;

Ben si on utilise les stats, à part les 3 dernières, c'est un très mauvais conseil...

[Zohaib-fk]

Les commandes ci-dessus m'aident, ce que j'ai obtenu dans les messages du forum dans le passé, lorsque la taille de ma base de données PS est passée à 3 Go et plus et que mon hébergement Web a une limite maximale de 3 Go de taille de base de données.

De plus, en raison de la taille de la base de données de 3 Go, de la RAM limitée et des ressources CPU, mon application Web est devenue lente.

Les anciennes versions appellent le compte Marketplace en arrière-plan, le back-office fonctionne donc également lentement. J'ai partagé le lien sur la façon de le désactiver dans le message précédent.

[Mediacom87]

Il y a 1 heure, Zohaib-fk a dit :

Les commandes ci-dessus m'aident, ce que j'ai obtenu dans les messages du forum dans le passé, lorsque la taille de ma base de données PS est passée à 3 Go et plus et que mon hébergement Web a une limite maximale de 3 Go de taille de base de données.

De plus, en raison de la taille de la base de données de 3 Go, de la RAM limitée et des ressources CPU, mon application Web est devenue lente.

Les anciennes versions appellent le compte Marketplace en arrière-plan, le back-office fonctionne donc également lentement. J'ai partagé le lien sur la façon de le désactiver dans le message précédent.

Il serait bon de faire attention à ce que vous partagez sur ce forum, surtout avec votre signature qui donne l'impression que vous êtes un expert et donc que ce que vous dites est parole d'évangile.

Non, vider intégralement une table de la base de données n'est jamais une bonne idée, sauf s'il n'y a pas de moyen de différencier proprement les données, comme par le biais d'une date de création.

Non, restaurer la sauvegarde d'une base de données à partir de son hébergement n'est pas une solution de sécurité ou de contrôle de ce que l'on fait sur sa boutique, c'est juste la dernière solution disponible si toutes les autres solutions n'ont pas fonctionné.