Plus de nouveaux produits sur la page d'accueil (aléatoire, non reproductible)

[llbbay]

Bonjour,

Depuis un moment je me retrouve avec un problème aléatoire : parfois le bloc des nouveaux produits sur la page d'accueil affiche "aucun nouveau produit à l'heure actuelle" alors que le module est configuré pour qu'il affiche les 12 derniers produits ajoutés sur les 60 derniers jours (sachant que quasiment chaque jours des nouveaux produits sont ajoutés). Je parle uniquement du module qui affiche les nouveaux produits en page d'accueil, la page spécifique des nouveaux produits du site elle fonctionne correctement donc ça semble clairement lié au module.

Résultat sur la page d'accueil quand ça se produit :

Pour les infos techno (tout est en latest stable) :

• Prestashop (1.6.1.23 + module tout update) + Nginx (+ pagespeed) + php-fpm (7.2) + mySQL Percona (avec ou sans xtradbcluster, peu importe)
• CentOS 7.6.avec Selinux activé (enforcing)
• Cloudflare

Pour les tests effectués (avec et sans cloudflare même si aucune proba que ce soit lié):

• en HA (load balancer layer 7 front actif/passif + cluster xtradbcluster + multiples serveurs applicatifs)
• en standalone

Le résultat est identique et malgré des dizaines d'essais divers et variés le problème n'est absolument pas reproductible (ajout de nouveaux produits en masse, suppression, modification client etc). Une fois c'est arrivé du temps de midi alors que personne n'était connecté si sur le back ni sur le serveur (ssh). A noter, une fois j'ai vidé le cache depuis le back office et les produits sont revenus. Sans action de ma part les produits reviennent au bout de quelques minutes.

Ce que j'ai écarté :

• un cron qui mettrais le bazar (backups/tâches dans la nuit heure française et toujours nice +19)
• un souci de perf (on est sur du gros serveur dédié pas du VPS)
• un souci de droit (avec selinux la gestion est différente grâce aux contextes d'exec/sec/role, si la conf selinux est foireuse ça marche pas, point final, ce qui protège de tout un tas de bêtises qu'on voit souvent écrite sur les chown/chmod)
• des attaques (tout est monitoré)
• des pics de traffics (idem tout est monitoré)

Niveau logs, rien (système, Nginx, PHP, kernel, bien évidemment Presta en mode debug et verbose max sur le reste). L'espace disque consommé et les inodes ne bougent pas d'un iota.

Passons sur du concret, pour l'exemple, la dernière fois c'était mercredi 24 avril 2019 : aucune intervention de ma part, les produits sont revenus quelques minutes après. Au niveau du serveur en lui même, légère montée du load vers 10h55 mais rien de bien inquiétant :

Au niveau du disque, on voit un tout petit flush du cache mais celui-ci se situe bien après, donc je l'ai écarté de la cause (usage de la partition où se situe le cache) :

Vers 11h10 un petit pic d'I/O en read, mais une minute après la constatation du problème, donc ça ne semble pas corrélé.

Globalement la base n'a pas eu de burst spécifique à cette heure là (graphe sur la semaine) :

Mais on voit un petit pic quand même sur le moment en SELECT :

La seule partie qui peut donner une piste est au niveau innodb (range dans l'heure) :

Quelqu'un a-t-il déjà rencontré ce type problème ?

Merci pour votre aide!

[Eolia]

Cela arrive lorsque l'on modifie un tpl et que recompiler si modification est sur oui.

Ces 2 modules (Mis en avant et Meilleures ventes) ont un souci sur la reconstruction de leur cache (cache_id) qui oblige à vider complètement le cache pour qu'ils se reconstruisent.

J'avoue ne pas en avoir cherché vraiment la cause (pas pris le temps^^) mais ce souci existe depuis 2015 au moins

[doekia]

Déjà des éléments de ta recette me choquent:
Nginx (+ pagespeed) + php-fpm (7.2)   Cloudflare

Tu as pourtant l'air d'avoir un système décent même si tu ne précise pas ce que c'est que "gros VPS"

 

Après ton problème me semble lié à ton module - celui-ci créer une version contenu vide et la garde dans son cache.

Le code de prestashop n'est pas atomique, 2 visites simultanée, l'un lock la table, l'autre expire le timeout et enregistre dans le cache ...

[llbbay]

Merci des infos @Eolia mais la reconstruction du cache n'intervient que si il y a modification ? Pour mon cas pas de modification de template et la recompilation est sur "jamais" (je switch juste momentanément quand il y a un changement).

Smarty :

Cache : 

Rien de choquant dans les params ? J'avais fais pas mal de testing au niveau Prestashop c'était avec ce set que j'atteins les meilleurs perf (donc sans tuning hors presta que j'ai également).

lol @doekia pour ma stack technique qu'est-il de choquant ? 

Le module est celui de base je ne l'ai pas touché. Pas de VPS que du bare metal, je ne détaillerais pas les specs mais je comparais par rapport à beaucoup qui tournent sur un VPS OVH 1vCPU/2GRAM, là impossible que ce soit un bottleneck hardware.

Edited May 1, 2019 by llbbay (see edit history)

[Eolia]

Pas de cache serveur avec Prestashop il le gère très mal. Donc mettre sur système de fichier et ensuite sur non

[llbbay]

Ah ok merci du tips j'avais pas de visu là dessus, donc selon vous ça peu être lié au système de cache interne presta 🤔? Je risque de perdre en perf un peu non ? Je referais des tests ce soir pour vérifier si il y a un impact. 

Edited May 1, 2019 by llbbay (see edit history)

[doekia]

il y a une heure, llbbay a dit :

je switch juste momentanément quand il y a un changement

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

 

il y a une heure, llbbay a dit :

lol @doekia pour ma stack technique qu'est-il de choquant ? 

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

cheminement d'une données sql > static php -> memcache -> smarty -> compile -> cache -> html -> pagespeed -> nginx -> clouflare

cloudflare est incapable de détecter un changement bdd/php => no-cache ou englué dans un snapshop de page

pagespeed est incapable de détecter un changement bdd/php => no-cache ou englué dans un snapshop de page

il y a une heure, llbbay a dit :

VPS OVH 1vCPU/2GRAM

1vcpu net + système, 1vcpu bdd, 1vcpu php - c'est en gros le minimum pour avoir qqchose de potable. Mais comme ce genre de VPS coûte au final plus cher qu'un dédié 4c/8t cpu+32GBram+SSD, outre qu'il ne faut pas faire tourner l'hyperviseur, ni subir la charge d'un VPS voisin, je ne comprends pas les choix de VPS de toute manière.

 

Toute choses égale par d'ailleurs je ne vois pas pourquoi tu envisages un pb harware ou perf. Tu as ici 4 couches de cache (à mon sens très superflues) et j'imagine que tu a oublié d'en mentionner quelques une (varnish? glusterfs? lvm? pour ne citer que les plus courant). Les modules sont les coupables ici. c'est 100% certain.

 

il y a une heure, llbbay a dit :

Je risque de perdre en perf un peu non ?

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). Consultes ton analytics temps réels, regardes quand tu as 100 connectés, combien sont sur les mêmes pages (au mieux c'est 3 page d’accueil, 2 tunnel, le reste dispersé sur tout le catalogue). Si ton catalogue est important tu as donc 4 versions de ce dernier en cache x par le nombre de groupe, de langue, de shop, ... Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

D'ailleurs le juge impartial c'est ta search console statistique des pages. ta moyenne est-elle meilleurs avec tout ça, proche d'un mécanisme Rube Goldberg, les temps mesurés par GG sont ils stable ou observes-tu de gros écart minimum maximum?

Sur aucune des installations que je gère sauf une je n'ai de cache autre que ceux de smarty. L'exception, imposée par une agence SEO dont le prix "justifie" la "compétence" auprès du client, nous avons du mettre en place un cron qui purge les caches toutes les 4h - et le client invalide également le cache manuellement à chaque changement du catalogue....

 

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

 

Edited May 1, 2019 by doekia (see edit history)

[Eolia]

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

[llbbay]

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté. Une possibilité que le problème vienne de là ?

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute, moins système (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare. Aucun rapport DB/PHP.

9 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

9 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

9 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

9 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur... 
 

Merci à vous les gars  

Edited May 1, 2019 by llbbay (see edit history)

[doekia]

Bon ça tourne au pujila.

Donc je vais me retirer.juste une chose. Tu crois que le cache SQL. Celui du moteur, il n'utilise pas la RAM?

Désolé d'avoir voulu te donner mon avis

[Eolia]

il y a une heure, llbbay a dit :

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Ben avec un TTFB de 10 secondes à cause d'un module foireux, l'internaute attend déjà 10s avant d'avoir le moindre css... Si tu penses que ce n'est pas important^^

On raisonne sur des Presta optimisés avant de penser opti serveur mais souvent les utilisateurs pensent l'inverse: le Presta rame alors on booste de tous les côtés sans vraiment réfléchir à l'origine du problème.

Tu peux avoir un serveur aux petits oignons, si ton Presta est une bouze ca ne changera pas grand chose...

Et pour info, oui vider le cache (cache Smarty) force la recompilation (Smarty ne conserve pas "en mémoire" les compilations précédentes)

[llbbay]

15 minutes ago, Eolia said:

Ben avec un TTFB de 10 secondes à cause d'un module foireux, l'internaute attend déjà 10s avant d'avoir le moindre css... Si tu penses que ce n'est pas important^^

On raisonne sur des Presta optimisés avant de penser opti serveur mais souvent les utilisateurs pensent l'inverse: le Presta rame alors on booste de tous les côtés sans vraiment réfléchir à l'origine du problème.

Tu peux avoir un serveur aux petits oignons, si ton Presta est une bouze ca ne changera pas grand chose...

Et pour info, oui vider le cache (cache Smarty) force la recompilation (Smarty ne conserve pas "en mémoire" les compilations précédentes)

Ah oui bien sur!! Non quand je parlais de TTFB c'était plus un site parfaitement fonctionnel, entre 200ms et 600ms ça veut pas dire que 600ms ton site est moins véloce pour l'utilisateur final et que souvent si tout est bien fait un TTFB un peu plus haut c'est pas très grave si c'est parce qu'il y a un workflow d'opti derrière (normal y'a du processing) c'était dans ce sens  

Mon presta vanilla était carrément OK niveau optimisation, en fait avant d'entreprendre les travaux pour avoir l'optimisation finale la plus fine j'ai bossé sur le Presta vanilla d'abord, et le plus gros souci c'était les photos. Pagespeed permet la convertion automatique en webp, permet aussi de générer une image spécifique si tu as une image de 1000px*1000px sur une page c'est une icone 50px*50px tu auras une photo de cette taille. En tout cas à l'époque nativement c'était pas le cas sur Presta, après avec la 1.7, pê ? Pagespeed permet de faire tout un tas de truc cool aussi c'est assez impressionnant et en perf... dingue. Là avec le setup que j'ai c'est parfait (sauf les produits qui disparaissent de la page d'accueil parfois, ce qui était mon premier message ^^ mais la discussion est intéressante).

Et sur presta nativement (je veux dire sans toucher au code) il n'y a pas tant de possibilité d'opti que ça si ?

Et merci pour l'info sur le cache, très utile !

48 minutes ago, doekia said:

Bon ça tourne au pujila.

Donc je vais me retirer.juste une chose. Tu crois que le cache SQL. Celui du moteur, il n'utilise pas la RAM?

Désolé d'avoir voulu te donner mon avis

Ne le prend pas du tout comme ça, avis constructif et intéressant sur bien des points, mais pas forcément exact sur d'autre, j'ai essayé d'étayer. J'ai compris ton message peut-être dans le mauvais sens mais il m'a parut assez incisif, j'ai suivi le ton  ça reste du technique c'était pour clarifier

Pour les VPS gamme OVH à mon avis je pense que tu peux faire tourner un petit truc sur un VPS 2 vCPUs, il peut y avoir un léger overcommit sur la gamme mais ils n'abusent pas, derrière l'hyperviseur fait bien le boulot.

Je n'ai pas saisi la question sur le cache SQL du moteur. 

Edited May 1, 2019 by llbbay (see edit history)

[doekia]

Mon prochain message va être flaggue, tu l'aura demain ou jamais selon l'humeur des nouveaux filtre être si oui ou non je brise un des vecteur de flouze

[doekia]

Trop drôle le filtre planté. Message perdu !je disais en gros j'appelle un chat un chat Et un vps un gaufrier. Meme perf.

Quand tu dis il y a peu de marge/option côté PS. C'est plutôt bon signe selon moi. Ça veux dire c'est déjà bien. Même si côté appli je connais pas mal de code bien pourri.

Kiss c'est le maître mot.donc un minimum de couche et du bon matos et on est en place pour 650 commandes/heure... Si si

[llbbay]

Je n'en doute pas  mais pour moi ça reste un peu light pour de la prod. Et t'es un peu dur sur les VPS, sans parler hyperviseur ça dépend surtout si ton provider overcommit *16 ou si 1 vCPU= 1CPU), franchement j'ai vu des providers hyper honnêtes avec des perf pas dégueu du tout! Les gaufriers c'est OK aussi.

Bon sinon j'ai désactivé la partie memcache, rien de particulier à signaler, j'ai mis un check toutes les 2min sur la page d'accueil comme ça je serais alerté direct...

Juste @doekia j'aurais aimé comprendre pour finir quand tu parlais stockage RAM c'est niveau moteur SGDB ? 

bonne soirée

Edit : ok jviens de voir ça https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/ jcomprend mieux ta réaction sur php 7.2 j'étais persuadé d'avoir vu dans un changelog d'une 1.6.1.x que php 7.2 était ok (sortie en novembre 2017 quand même)... jamais eu aucun souci perso 

Edited May 1, 2019 by llbbay (see edit history)

[doekia]

#   v1.6.1.20 - (2018-06-27)
    BO: PHP 7.2 compat - Fix fatal error
#   v1.6.1.18 - (2018-02-05)
    CO: Fix PHP 7.1 compatibility

https://github.com/PrestaShop/PrestaShop/pull/12643#event-2154991932

...