Jump to content

Prestashop 1.7.7.3 Back Office très lent, rame. OVH en cause ?


Recommended Posts

Bonjour tout le monde,

J'espère que vous allez bien en ce début de mois de juillet.

Je vous écris car je rencontre un soucis sur le prestashop d'une cliente. J'ai farfouillé partout sur Google, partout sur ce forum et j'ai testé plein de solution mais rien y fait le back office rame énormément contrairement au front office qui n'est pas des plus rapide mais bon c'est un prestashop... Et contrairement au back office c'est une fusée.
 

Voici les caractéristiques du site de ma cliente :

Prestashop en version  : 1.7.7.3

Thème utilisé : https://addons.prestashop.com/fr/themes-animaux/43143-wiser-pets-store.html

Hébergement : OVH Offre Pro 2014

Voici les symptômes :

- Le site rame en Back Office au point parfois de mettre 30 secondes à afficher une page

- Le site rame moins en Front Office

- Installé en local sur wampserver le Back Office rame plus. J'ai mis plus bas, 2 captures. 1 pour le profiling en local et 1 pour le profiling en ligne. On voit que cela rame dès le chargement de config

- La base de données pèse 80 mo dont 80% du poids sont la table connections et guests

Voici les interventions tentées :

- Modifier le fichier Tools et la variable is_addons_up à false

- Nettoyer, activer, désactiver la cache,

- Chercher des modules qui se seraient greffés mais rien de ce côté là.

Profiling :

- Profiling du site en ligne : https://www.dropbox.com/s/wj8vwn3v9ukc7c8/prestashop_en_ligne.jpg?dl=0

- Profiling du site en local : https://www.dropbox.com/s/l1a4ve3phn1oi22/prestashop_local.png?dl=0


Voilà vous savez tout. Je suis ouvert à toute suggestion car là j'ai tout épuisé. Sachant qu'en contactant OVH, bien sûr ils m'ont dit de désactiver les plugins et les thèmes pour voir si ça allait plus vite. Mais du coup pourquoi en Local ça irait vite et pas en ligne ?

Merci d'avoir pris le temps de me lire.

Je reste à votre disposition si vous avez des questions.

Cordialement.

Momox.

Share this post


Link to post
Share on other sites

On 7/1/2021 at 3:58 PM, Momox said:

 

 

Bonjour tout le monde,

J'espère que vous allez bien en ce début de mois de juillet.

Je vous écris car je rencontre un soucis sur le prestashop d'une cliente. J'ai farfouillé partout sur Google, partout sur ce forum et j'ai testé plein de solution mais rien y fait le back office rame énormément contrairement au front office qui n'est pas des plus rapide mais bon c'est un prestashop... Et contrairement au back office c'est une fusée.
 

Voici les caractéristiques du site de ma cliente :

Prestashop en version  : 1.7.7.3

Thème utilisé : https://addons.prestashop.com/fr/themes-animaux/43143-wiser-pets-store.html

Hébergement : OVH Offre Pro 2014

Voici les symptômes :

- Le site rame en Back Office au point parfois de mettre 30 secondes à afficher une page

- Le site rame moins en Front Office

- Installé en local sur wampserver le Back Office rame plus. J'ai mis plus bas, 2 captures. 1 pour le profiling en local et 1 pour le profiling en ligne. On voit que cela rame dès le chargement de config

- La base de données pèse 80 mo dont 80% du poids sont la table connections et guests

Voici les interventions tentées :

- Modifier le fichier Tools et la variable is_addons_up à false

- Nettoyer, activer, désactiver la cache,

- Chercher des modules qui se seraient greffés mais rien de ce côté là.

Profiling :

- Profiling du site en ligne : https://www.dropbox.com/s/wj8vwn3v9ukc7c8/prestashop_en_ligne.jpg?dl=0

- Profiling du site en local : https://www.dropbox.com/s/l1a4ve3phn1oi22/prestashop_local.png?dl=0


Voilà vous savez tout. Je suis ouvert à toute suggestion car là j'ai tout épuisé. Sachant qu'en contactant OVH, bien sûr ils m'ont dit de désactiver les plugins et les thèmes pour voir si ça allait plus vite. Mais du coup pourquoi en Local ça irait vite et pas en ligne ?

Merci d'avoir pris le temps de me lire.

Je reste à votre disposition si vous avez des questions.

Cordialement.

Momox.

Bonjour,

j'avais exactement le même problème que toi, et on m'a conseillé d'upgrader mon hébergement (j'avais la pro 2014 aussi). je viens de passer à la performance 1 et j'ai une base de donnée privée maintenant. Il paraît que ça va aller beaucoup mieux maintenant.

Je suis en train de chercher quel type de base je dois choisir car j'ai le choix entre Redis 4.0, PostgreSQL (du 9;5 au 12), MySQL (5,7 ou 8 ), MariaDB (10,2 à 10,5) et je dois ensuite modifier un fichier de config pour re-creer le lien avec la base (je ne sais pas encore quel fichier je dois modifier).

Comme nous avons des similitudes dans nos problématiques, je te propose qu'on suive nos posts pour solutionner la vitesse de cargement de nos sites respectifs  (je viens juste créer un post sur quel type de base privé choisir et quel fichier modifier) :)

Rashel

Share this post


Link to post
Share on other sites

Bonjour Rashel,

En effet notre cas est très similaire voir identique.

Concernant le choix du type de base de données, pour ma part, je pense choisir le même type que celui qui équipé déjà mon Prestashop' afin d'éviter de le perturber. Concernant ton fichier, toute la partie liée à la base de données se trouve dans :

/app/config/parameters.php

Pour éditer le fichier, utilise Notepad ++.

Je vais remonter tout cela à ma cliente et au fur et à mesure de mon avancement je te ferais un retour.

Bonne journée.

Share this post


Link to post
Share on other sites

2 hours ago, Momox said:

Bonjour Rashel,

En effet notre cas est très similaire voir identique.

Concernant le choix du type de base de données, pour ma part, je pense choisir le même type que celui qui équipé déjà mon Prestashop' afin d'éviter de le perturber. Concernant ton fichier, toute la partie liée à la base de données se trouve dans :

/app/config/parameters.php

Pour éditer le fichier, utilise Notepad ++.

Je vais remonter tout cela à ma cliente et au fur et à mesure de mon avancement je te ferais un retour.

Bonne journée.

 

Bonjour, il serait préférable d'avoir le lien vers le site pour mieux comprendre le problème.

Un site lent utilise généralement :

- images trop lourdes

- trop de sliders ou d'animations

- un theme trop complexe ou mal écrit

- certains modules qui posent des problèmes

- un dbase  mal optimisée

- trop de modules activés

- un php.ini avec des valeurs trop basses

- trop de plugins/modules qui gèrent la cache 

- trop de connexions externes avec des modules tels que fb/chat/whatsapp/analytics etc...

NB. Sur votre site local, vous utilisez php 7.4. Il n'est pas compatible avec votre PS.

 

Ma proposition est :

- vérifiez la taille des images, utilisez une meilleure compression et évitez les fichiers .png

- désactiver les modules qui ne sont pas utilisés, aussi bien sur desktop que sur mobile

- en même temps utiliser le moins de modules possible

- supprimer certains sliders s'ils sont présents en abondance

- dans phpmyadmin effectuer une optimisation automatique des tables

- vérifier que le site n'a pas de redirection (domaine/prestashop est différent de domaine/prestashop/votresite/, la deuxième option a quand même un délai de chargement si je recherche domaine/prestashop et je suis redirigé vers/votresite/)

- Si possible, désactivez plusieurs modules de chat/whatsapps, choisissez l'un ou l'autre.

 

J'espère que ça aide, désolé pour le français, j'utilise le traducteur google. 😅

Danny

Edited by Danny (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites

Bonjour Danny,

Ton français traduit est impeccable.

Je te remercie pour tes propositions. Mais je ne pense pas que cela soit interne au thème, sinon le site front office ramerait. Or ce n'est pas le cas. C'est vraiment que l'administration (back office). Sur les captures d'écran que je vous ai transmises on voit que le site est lent à charger avant l'appel de config. Qu'est-ce qui peut altérer cette durée ?

Le site internet :

https://www.protec-sabots.fr/

Migration faite :

Pour information, ma cliente est passée sur un performance1. Le site en front office est désormais vraiment très fluide. Pour le back office, il y a du mieux mais ce n'est pas suffisant. On voit une légère amélioration mais ce n'est pas assez.

php.ini :

Si je dois modifier le php.ini quelles sont les valeurs qui peuvent agir dessus ?

Base de données :

Les tables ps_connections et ps_guest ont toutes les deux 600 000 lignes. Ces lignes peuvent-elles être supprimées ? Le soucis pourrait-il venir de là ?

Modules dans l'administration :

Au niveau des modules de l'administration, voici ceux chargés dans l'administration. En plus de cela, seul paypal et stripe sont chargés au niveau des points d'accroche de l'administration. Certains sont-ils facultatifs et pourrait être gênants ?

https://www.dropbox.com/s/pvb7598vqf1lbky/module_admin.PNG?dl=0

Merci pour le temps que vous prenez à m'aider.

Ronan.

Share this post


Link to post
Share on other sites

48 minutes ago, Momox said:

Bonjour Danny,

Ton français traduit est impeccable.

Je te remercie pour tes propositions. Mais je ne pense pas que cela soit interne au thème, sinon le site front office ramerait. Or ce n'est pas le cas. C'est vraiment que l'administration (back office). Sur les captures d'écran que je vous ai transmises on voit que le site est lent à charger avant l'appel de config. Qu'est-ce qui peut altérer cette durée ?

Le site internet :

https://www.protec-sabots.fr/

Migration faite :

Pour information, ma cliente est passée sur un performance1. Le site en front office est désormais vraiment très fluide. Pour le back office, il y a du mieux mais ce n'est pas suffisant. On voit une légère amélioration mais ce n'est pas assez.

php.ini :

Si je dois modifier le php.ini quelles sont les valeurs qui peuvent agir dessus ?

Base de données :

Les tables ps_connections et ps_guest ont toutes les deux 600 000 lignes. Ces lignes peuvent-elles être supprimées ? Le soucis pourrait-il venir de là ?

Modules dans l'administration :

Au niveau des modules de l'administration, voici ceux chargés dans l'administration. En plus de cela, seul paypal et stripe sont chargés au niveau des points d'accroche de l'administration. Certains sont-ils facultatifs et pourrait être gênants ?

https://www.dropbox.com/s/pvb7598vqf1lbky/module_admin.PNG?dl=0

Merci pour le temps que vous prenez à m'aider.

Ronan.

Tous les modules traitant des statistiques PS peuvent être désactivés.

Généralement, ceux comme Google Analytics sont plus fiables. Ceux du PS ne font qu'alourdir l'ensemble.

La lenteur du back office peut aussi être causée par une forme mal rédigée.

 

Les valeurs qui peuvent être augmentées à l'aide de cpanel concernant php.ini sont:

memory_limit = set 1024M,

opcache.memory_consumption = set 128M,

xcache.size = set 128M,

max_input_vars = set 1400,

output_buffering = set 4096,

realpath_cache_size = set 4096K,

realpath_cache_ttl = set 120 (pour un système qui modifie peu les fichiers de la boutique, la valeur peut aussi être augmentée)

Si vous avez déjà ces valeurs (ou supérieures) dans php.ini, ne les modifiez pas.

 

Pour le database, en utilisant phpmyadmin il y a la possibilité d'optimiser les tables automatiquement. Déjà cela peut aider sans rien toucher.

Ps_guest et ps_connections ont à voir avec les statistiques. Vous pouvez vider les tableaux, mais vous perdrez les statistiques enregistrées.

 

Danny

Share this post


Link to post
Share on other sites

Salut,

J'ai déjà eu un problème similaire mais avec en plus des ralentissements en front, assez violents.

J'étais déjà sur un performance 1, avec BDD privée. J'ai un contact chez OVH Pro donc je leur demande s'ils ont des solutions, et ils disent que cela vient du site, d'une requête trop lente.

Assez naïf je les crois, j'avais en plus réalisé pas mal de développements dessus (gestion de date en temps réel, des trucs relou).

Mais le problème perdure quoi que je fasse, avec de surcoit énormément de coupure sur ce cluster en particulier (pas de chance me dit OVH).

Le client en ayant marre, il décide de prendre son propre hébergement chez O2switch, et on fait la bascule à titre commercial.

Depuis le site fonctionne à merveille... 5€/mois puisque tarif unique, je ne sais pas comment ils s'y retrouvent mais ça fonctionne.

On conserve nos clients historiques chez OVH car on possède une assez grosse base, mais pour les projets où on sait qu'il va y avoir besoin de ressources ou des optimisations poussées de vitesse, on va chez O2switch maintenant.

Le service (via chat en ligne) est impeccable, réponse en quelques secondes ou minutes AU PIRE.

Donc mon conseil, puisque tu possèdes un site en ligne chez OVH et un site en local, essaye de prendre 1 serveur O2switch (sites, bases, et ressources illimitées) et de tester de le mettre en ligne. Tu verras la différence je pense.

Et si tu n'es pas satisfait, au pire ça t'auras coûté 5€ de services et une heure de test tout au plus :)

PS : "une forme" c'est probablement la trad de "un formulaire"

Edited by Shonen (see edit history)

Share this post


Link to post
Share on other sites

31 minutes ago, Momox said:

Je vais checker tout ça. 

Que veux-tu dire par : "une forme mal rédigée" ? Je pense qu'il y'a une erreur de trad.

"un module mal écrite",  un module qui a des problèmes.

Danny

Share this post


Link to post
Share on other sites

Bonjour, 

Le problème a été résolu en faisant appel à un prestataire externe expert en Prestashop' qui a installé un module de cache appelé "Jpresta - Page Cache Ultimate". De plus, dans Paramètres avancés > Performance > Cache, dans la partie "Utiliser le cache", la valeur est désormais à Non afin que le module puisse gérer la cache de son côté.

Depuis cette intervention, l'administration comme le front office sont ultra rapides.

Merci pour votre temps.

Share this post


Link to post
Share on other sites

il y a 10 minutes, Momox a dit :

Bonjour, 

Le problème a été résolu en faisant appel à un prestataire externe expert en Prestashop' qui a installé un module de cache appelé "Jpresta - Page Cache Ultimate". De plus, dans Paramètres avancés > Performance > Cache, dans la partie "Utiliser le cache", la valeur est désormais à Non afin que le module puisse gérer la cache de son côté.

Depuis cette intervention, l'administration comme le front office sont ultra rapides.

Merci pour votre temps.

Heureusement que vous avez trouvé un EXPERT PRESTASHOP pour vous aider à installer un module ... bonne chance pour la suite, avec ce module.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More