.png.022b5452a8f28f552bc9430097a16da2.png)
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.