L E O Posted September 3, 2015 Share Posted September 3, 2015 Bonjour, Depuis que j'ai fait évoluer un site en production de la 1.6.0.9 vers la version 1.6.1.1 la différence est plus que flagrante aussi bien sur le FO que le BO. Le problème est que cela influe directement sur le chiffre d'affaires réalisé quotidiennement alors que j'attendais plutot le contraire. Pourquoi cette nouvelle version est-elle si lente (temps de chargement x2 à 5) et surtout comment y remédier ?? Je peux fournir toute information technique pour faire avancer le sujet. Merci ! Link to comment Share on other sites More sharing options...
coeos.pro Posted September 3, 2015 Share Posted September 3, 2015 vous avez bien activé tous les systèmes de caches ? smarty, SQL, fichiers... Peut on savoir ce que vous avez dans Paramètres avancés > Performances, dans le bloc smarty Link to comment Share on other sites More sharing options...
L E O Posted September 3, 2015 Author Share Posted September 3, 2015 (edited) Merci pour cette première réponse rapide !! Dans Paramètres avancés > Performances j'ai ceci (images jointe) Avant la mise à jour, j'avais vidé le dossier /cache en ne gardant que index.php et class_index.php Cette configuration est-elle correcte ? Vous faut-il d'autres infos ? D'autre part (autre sujet) j'ai du positionner à Oui l'option Désactiver toutes les surcharges pour pouvoir générer les factures sinon cela ne fonctionne plus comme avant (1.6.0.9) alors que le site est en prod et que le mode debug n'est pas activé bien sûr, c'est incompréhensible !! Edited September 3, 2015 by L E O (see edit history) Link to comment Share on other sites More sharing options...
coeos.pro Posted September 3, 2015 Share Posted September 3, 2015 il faut charger l'image et ensuite cliquer sur un bouton insérer dans le texte ou quelque chose comme ça D'autre part (autre sujet) j'ai du positionner à Oui l'option Désactiver toutes les surcharges donc tous les modules ayant un override ne fonctionnent pas ou mal... Link to comment Share on other sites More sharing options...
L E O Posted September 3, 2015 Author Share Posted September 3, 2015 Désolé, maintenant voici l'image. Pour l'option "Désactiver toutes les surcharges" je comprends que ce n'est que pour le mode debug ce qui n'est pas le cas actuellement mais l'option quand même est prise en compte. Link to comment Share on other sites More sharing options...
coeos.pro Posted September 3, 2015 Share Posted September 3, 2015 D'autre part (autre sujet) j'ai du positionner à Oui l'option Désactiver toutes les surcharges pour pouvoir générer les factures sinon cela ne fonctionne plus comme avant (1.6.0.9) 1- c'est quoi le problème avec les factures 2- si tu remet à Non, la boutique est plus rapide ? 3- tu n'as pas changé d'hébergeur entre temps ? Link to comment Share on other sites More sharing options...
natachaC Posted September 3, 2015 Share Posted September 3, 2015 je trouve moi aussi que les dernières version sont de plus en plus lentesle backoffice est truffé d'appel à des serveurs externes (PUB pourPresta, PUB pour les modules, etc) qui ralentissent les manipulationsle front est moins touché en mettant un bon module de cache pour palier perso sauf obligation j'installe pour mes clients la dernière version de 1.5 qui associé à un bon module de cache donne des temps de réponse honorables en frontj'ai aussi surchargé les templates de l'admin pour supprimer l'affichage des trucs inutiles en production Link to comment Share on other sites More sharing options...
coeos.pro Posted September 3, 2015 Share Posted September 3, 2015 le backoffice est truffé d'appel à des serveurs externes (PUB pourPresta, PUB pour les modules, etc) qui ralentissent les manipulations il est possible de "simplifier" la page modules dans le back office avec https://www.prestashop.com/forums/topic/459836-pas-de-mise-%C3%A0-jour-merci/ Link to comment Share on other sites More sharing options...
L E O Posted September 3, 2015 Author Share Posted September 3, 2015 (edited) Bon, je recadre ce post sur le premier sujet, la lenteur de PS 1.6.1.1 et on oublie le pb des factures qui fait déjà l'objet d'un autre post (sans réponse pour le moment). Donc, est que ma config de performance vous parait bonne ? A quoi correspond la nouvelle option ci-dessous pour laquelle il n'y a pas de doc : Vider le cache Ne jamais vider les fichiers du cache Vider le cache chaque fois qu'il y a une modification Je n'ai pas changé d'hébergeur et le serveur est un dédié chez OVH : Processeurs : 8 RAM : 64 Go HD : 1To Pour NatachaC, qu'est-ce que tu appelles un bon module de cache ? Edited September 3, 2015 by L E O (see edit history) Link to comment Share on other sites More sharing options...
coeos.pro Posted September 3, 2015 Share Posted September 3, 2015 A quoi correspond la nouvelle option ci-dessous pour laquelle il n'y a pas de doc : Vider le cache Ne jamais vider les fichiers du cache Vider le cache chaque fois qu'il y a une modification ça correspond au cache smarty, sélectionne Vider le cache chaque fois qu'il y a une modification Link to comment Share on other sites More sharing options...
L E O Posted September 4, 2015 Author Share Posted September 4, 2015 Si je sélectionne cette option cela signifie t'il que tout le cache smarty sera vidé à chaque modification d'une page, c'est à dire plusieurs fois par jour ? Dans mon cas le cache smarty contient près de 4 millions de fichiers et met plusiers jours pour se regénérer. Est-ce que cela ne risque pas de ralentir encore davantage PS ? Link to comment Share on other sites More sharing options...
Centaure Posted September 4, 2015 Share Posted September 4, 2015 Bonjour, moi je n'active pas ces trois option dans CCC : Réduction du code HTML Compression du JavaScript dans le code HTML Déplacer le code JavaScript à la fin car j'ai remarqué que ça ralentissait énormément le site ... à tester Link to comment Share on other sites More sharing options...
natachaC Posted September 8, 2015 Share Posted September 8, 2015 Pour LEO j'utilise ce module sur les sites de mes clients http://addons.prestashop.com/fr/referencement-seo-modules-prestashop/7939-page-cache.htmlil y en a d'autres mais pas essayé Link to comment Share on other sites More sharing options...
shionn Posted November 25, 2015 Share Posted November 25, 2015 J'ai aussi eu un cas de problème d'admin hyper lent (~30sec pour afficher la page des commandes) A l'aide de firebug j'ai observé de très nombreux appel à google analitycs. (plus de 2000). Du coup j'ai désactivé le module Google anal... Et voila Mon client est content. Link to comment Share on other sites More sharing options...
nazdupresta Posted December 28, 2015 Share Posted December 28, 2015 (edited) Bonjour a tous je viens lancer un gros HELP ME ! lol cela fait 3 jours que je m'arrache les cheveux sur la vitesse de mon presta qui met entre 7 et 19 sec de chargement !! c'est une horreur j'ai comparer avec pagespeed, yflow, gtmetrix ... toujours la meme catasptrophe j'ai installer SmushIt , ca ne change rien non plus malgré une soit disant compresion pagespeed me dit que gzip n'est pas installé , j'ai verifié le htaccess c'est activé a vrai dire je ne sait plus ou regarder juste que j'ai remarqué qu'en desactivant le cache prestashop j'ai gagné de la vitesse ... bizarre j'ai lu bcp de post mais il y en a que je ne comprend pas (compilation, sprite ...) ma config serveur : mon lien de site http://mafete.fr merci a ceux qui voudrons bien m'aider !! Edited December 28, 2015 by nazdupresta (see edit history) Link to comment Share on other sites More sharing options...
coeos.pro Posted December 28, 2015 Share Posted December 28, 2015 (edited) http://tools.pingdom.com/fpt/#!/bsRZdR/http://mafete.fr/dans les 3 secondes, ça peut encore aller (par rapport à ce que vous annoncez) mais des images à plus de 600ko (http://mafete.fr/modules/homeslider/images/0081576bf54c8f33ee6daf601db9b9bb3ad0a099_header-cot.png) c'est beaucoup trop surtout quand on voit l'image que c'est. Edited December 28, 2015 by coeos.pro (see edit history) Link to comment Share on other sites More sharing options...
nazdupresta Posted December 28, 2015 Share Posted December 28, 2015 http://tools.pingdom.com/fpt/#!/bsRZdR/http://mafete.fr/ dans les 3 secondes, ça peut encore aller (par rapport à ce que vous annoncez) mais des images à plus de 600ko (http://mafete.fr/modules/homeslider/images/0081576bf54c8f33ee6daf601db9b9bb3ad0a099_header-cot.png) c'est beaucoup trop surtout quand on voit l'image que c'est. Bonjour coeos ! tout d'abord merci beaucoup de repondre je viens d'activer le cache apc sur le servbeur , j'ai l impression que ca ameliore ya t il une solution en 'traitement de lot' pour optimiser toutes mes images d'un coup ? pour celle que tu cite , je vais la dégager , c'est plus simple !! encore merci ! coeos.pro Link to comment Share on other sites More sharing options...
coeos.pro Posted December 28, 2015 Share Posted December 28, 2015 dans préférences > images il y a une champ "Compression Jpeg", mais je ne sais pas si ça va fonctionner avec les images de slider. Link to comment Share on other sites More sharing options...
nazdupresta Posted December 29, 2015 Share Posted December 29, 2015 dans préférences > images il y a une champ "Compression Jpeg", mais je ne sais pas si ça va fonctionner avec les images de slider. Ok , merci beaucoup en tous cas Link to comment Share on other sites More sharing options...
doekia Posted December 29, 2015 Share Posted December 29, 2015 Compresser les images ne va rien faire gagner réellement en terme de vitesse du site. Les bon outils de cache sont sur un dédié très simple ... aucun cache autre que celui de smarty... l'operating system est bien plus efficace que toutes les miasmes. Optimisez le MySQL, ajustez les sticky bits éventuellement, un ram disk éventuel pour le répertoire cache... Vos pages doivent avoir un TTFB aux alentours de 700ms. Il est techniquement impossible de descendre en deçà de 300ms et de pouvoir absorber un audience raisonnable - tout ce qui prétend le contraire confond les objectifs. Oui les "caches" améliorent quand on a 3 produits et 1 visite par heure mais c'est - je l'espère - pas un objectif. Un shop sain reçoit plus de 50% de son trafic physique (connexion/s sur le web serveur), il doit donc être à même de tenir 5 connexion simultanées (socket serveur) sans refléter d'impact coté perf ... Si vous dépassez la seconde en TTFB (hors latence réseau), auditez vos modules et leurs hooks actif en front, surtout les modules faisant des appels aux services externes (tous ceux qui contiennent des curl, fsockopen, ...), nombres d'entre eux sont codés à l'arrache. Testez vos TTFB, connecté en tant que client et déconnecté. Une différence importante est presque toujours le reflet d'un appel externé codé à l'arrache. Link to comment Share on other sites More sharing options...
nazdupresta Posted December 29, 2015 Share Posted December 29, 2015 Compresser les images ne va rien faire gagner réellement en terme de vitesse du site. Les bon outils de cache sont sur un dédié très simple ... aucun cache autre que celui de smarty... l'operating system est bien plus efficace que toutes les miasmes. Optimisez le MySQL, ajustez les sticky bits éventuellement, un ram disk éventuel pour le répertoire cache... Vos pages doivent avoir un TTFB aux alentours de 700ms. Il est techniquement impossible de descendre en deçà de 300ms et de pouvoir absorber un audience raisonnable - tout ce qui prétend le contraire confond les objectifs. Oui les "caches" améliorent quand on a 3 produits et 1 visite par heure mais c'est - je l'espère - pas un objectif. Un shop sain reçoit plus de 50% de son trafic physique (connexion/s sur le web serveur), il doit donc être à même de tenir 5 connexion simultanées (socket serveur) sans refléter d'impact coté perf ... Si vous dépassez la seconde en TTFB (hors latence réseau), auditez vos modules et leurs hooks actif en front, surtout les modules faisant des appels aux services externes (tous ceux qui contiennent des curl, fsockopen, ...), nombres d'entre eux sont codés à l'arrache. Testez vos TTFB, connecté en tant que client et déconnecté. Une différence importante est presque toujours le reflet d'un appel externé codé à l'arrache. Bonjour doekia et merci ! a vrai dire , mon cerveau doit etre aussi long que mon site internet dans ce cas j'ai compris la deuxieme partie de ton message , effectivemment en supprimant certains caches j'ai gagné quelques secondes ! par contre pour l'histoire des sticky bit et TTFB , j'ai pas tout compris a ce que je devais faire :/ Link to comment Share on other sites More sharing options...
doekia Posted December 29, 2015 Share Posted December 29, 2015 ausculter tes modules ... le sticky bit c'est plus pour aider le système à décider ce qu'il doit prioriser dans les caches système. Actuellement avec les temps de réponse que tu donnes ton problème est (j'en suis convaincu à 90%) lié à des modules Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now