Lenteur chargement page du BO après MAJ 1.7.7.1

[azer]

Type d’install (nouvelle/MàJ) : de 1.7.6.7 vers 1.7.7.1
Version de PS : 1.7.7.1
Thème (défaut/perso) : Classic un peu modifié dans un theme enfant
Hébergement : OVH mutu
Version de PHP : 7.3
Navigateur(s) concerné(s) : base chromium

 

Bonjour, je viens de faire la maj de ma boutique et le BO est très lent, de 4 à 12 secondes selon les pages (il n y a que la page du tableau de bord qui rame pas et se charge tout de suite). C'est vraiment un problème pour l'exercice de mon travail, j'ai mon carnet de commande à exécuter demain lundi et ce ne sera pas dans de bonne condition, je me permet donc d'ouvrir un sujet sur ce problème après avoir lu les autres sujet de ce forum sur le même problème.

J'ai pu lire l'aide de Eolia:

"Désactivez l'appel à addons, dans /classes/tools.php vers la ligne 3352, remplacez 
protected static $is_addons_up = true;
Par:
protected static $is_addons_up = false;"

y a pas eu de changement.

J'ai aussi essayé ça:

Ouvrez /config/defines.inc.php
Passez la boutique en mode maintenance
À la line 42 environ vous trouverez define('_PS_DEBUG_PROFILING_', false);
Changez alors par define('_PS_DEBUG_PROFILING_', true);

Et voici les log lors du chargement de la page "produits" de ma boutique:

Load Time    4572 ms - You'd better run your shop on a toaster
Querying Time    304 ms
Queries    565
Memory Peak Usage    14.4 Mb
Included Files    1405 files - 12.13 Mb
PrestaShop Cache    - Mb
Global vars    0.47 Mb
PrestaShop Version    1.7.7.1
PHP Version    7.3.20 (OK)
MySQL Version    5.6.50-log (OK)
Memory Limit    512M
Max Execution Time    165s
Smarty Cache    enabled
Smarty Compilation    never recompile
     Time    Cumulated Time    Memory Usage    Memory Peak Usage
config    4526 ms    4526 ms    12.37 Mb    12.40 Mb
__construct    0 ms    4526 ms    - Mb    12.40 Mb
init    19 ms    4545 ms    0.85 Mb    13.31 Mb
checkAccess    0 ms    4545 ms    - Mb    13.31 Mb
setMedia    6 ms    4551 ms    0.49 Mb    13.71 Mb
postProcess    0 ms    4551 ms    - Mb    13.71 Mb
initHeader    15 ms    4566 ms    0.33 Mb    14.08 Mb
initContent    0 ms    4566 ms    - Mb    14.08 Mb
initFooter    0 ms    4566 ms    0.01 Mb    14.08 Mb
display    6 ms    4572 ms    0.19 Mb    14.38 Mb

 

Est ce que vous savez pourquoi les délais sont si long ?

Merci d'avance pour votre aide.

Cordialement.

[Divine]

Hello, j'ai eu aussi des grosses lenteurs lors d'une installation vierge de la version 1.7.7.1 et j'ai remarqué que l'activation de la version 7.2 de PHP au lieu de 7.3 améliorait un peu la vitesse de chargement. Peut-être pourrais-tu essayer ?

[azer]

Bonjour et merci de votre participation, c'est ce à quoi j'ai pensé et j'ai moi aussi remis php 7.2 sur mon serveur. Il y a les facture qui peuvent être téléchargé instantanément au lieu de ramer et de rare page qui ne rame pas, comme international/location/zones-countries-states. Pour tout le reste du back-office ça n'a pas changé ça rame.

Sinon sur les adresses de mes clients je vois que le code postal est écrit après le nom de la ville (exemple: "Eguzon, 36270"), c'est bizarre, est ce que ça vous fait ça aussi ?

[azer]

Ne trouvant pas de solution concrète j'ai choisi de faire une restauration via FTP hier le 31/01 à 23h15.

Sur l'interface ovh la restauration propose au plus une restauration de 2 semaines, les semaine sont compté de dimanche en dimanche (à 1h du matin).

Pas de bol j'ai fait fait ma maj le samedi 23.. donc ça ma restauré ma boutique après avoir appliquer la maj..

Du coup je souhaite me tourner vers l'option de restauration du module 1-Click Upgrade, les choix de restauration proposé sont les suivant:

La sauvegarde date du 23 novembre 2020.

Y a t il un risque d'utiliser ce procédé ? L'ancienneté de la sauvegarde va être un problème ? Est ce que ça restaure la base de donnée ? Est ce que ça va écraser toute l'évolution du stock de ma boutique et toutes les commande passées depuis le 23/11/2020 ?

Merci de m'éclairer sur le fonctionnement de cette option de ce module car il n y a aucune infos.

 

[Talas]

On 2/1/2021 at 12:20 AM, azer said:

Ne trouvant pas de solution concrète j'ai choisi de faire une restauration via FTP hier le 31/01 à 23h15.

Sur l'interface ovh la restauration propose au plus une restauration de 2 semaines, les semaine sont compté de dimanche en dimanche (à 1h du matin).

Pas de bol j'ai fait fait ma maj le samedi 23.. donc ça ma restauré ma boutique après avoir appliquer la maj..

Du coup je souhaite me tourner vers l'option de restauration du module 1-Click Upgrade, les choix de restauration proposé sont les suivant:

La sauvegarde date du 23 novembre 2020.

Y a t il un risque d'utiliser ce procédé ? L'ancienneté de la sauvegarde va être un problème ? Est ce que ça restaure la base de donnée ? Est ce que ça va écraser toute l'évolution du stock de ma boutique et toutes les commande passées depuis le 23/11/2020 ?

Merci de m'éclairer sur le fonctionnement de cette option de ce module car il n y a aucune infos.

 

Bonjour, avez-vous finalement résolu votre problème ?

[azer]

Je sais plus ce que j'avais fait mais j'était retourné en 1.7.6.9 et php 7.2. Il me semble que mon erreur venait du fait que j'ai d'abord mis mon serveur en php 7.3 avant de lancer la maj de presta. Mais hier j'ai retenté une maj vers 1.7.7.7, j'ai bien laisser mon serveur en php 7.2 et ça a bien fonctionné. Sauf.. que.. grosse blague.. les shortcodes ne fonctionnent plus alors la totalité des mes produits sont présenté sur page CMS et les vignettes des produit s'affiche grace à des shortcodes de type "{product:98}".. Du coup ma boutique est impraticable pour le client, aucun produit ne s'affiche, à la place des produit il y a les shortcodes qui s'affichent. Je viens de lancer une restauration OVH..

Auriez vous une idée d'un moyen d'afficher la vignette d'un produit (comme dans une catégorie) sur une page CMS ? Je peux payer via Paypal la valeur de la prestation si nécessaire si ça nécessite du travail de dev.

Edited August 31, 2021 by azer (see edit history)