Minimachines est très lent voire même totalement inaccessible ces derniers jours. Les billets de bons plans et la page Mistermatos sont plus ou moins Hors Service depuis lundi… Le succès du Black Friday et du Cyber Monday ont mis à genoux le système et aujourd’hui, je suis dans l’incapacité de le faire fonctionner comme avant.
J’essaye de trouver une solution au problème mais ce n’est vraiment pas simple. Je sais déjà que la publication de ce simple billet va probablement faire tomber le site et le mettre hors service. Mais il faut bien que je vous tienne au courant.
C’est très désolant puisque j’ai pas mal de choses à publier et que je suis pour le moment dans l’incapacité de le faire. J’espère que tout va revenir à la normale rapidement… En attendant, si vous avez une bonne expérience en développement sous WordPress et un peu de temps devant vous, je suis à la recherche de quelqu’un pour développer une extension afin de mieux gérer le site.
Bon courage Pierre. On saura être patient !
Bonjour,
Je n’ai aucune compétence, mais félicitations pour le travail effectué et les informations de qualité. Serait-il possible de « cacher » le site avec cloudflare qui fait cache en frontal et limite les accès, voir la solution haveIBeenPwned qui utilise ce service pour limiter les coûts d’infrastructure?
je n’ai rencontré aucun problème, je ne m’étais rendu compte de rien. Donc tout n’est pas noir
@Mxte29Fr: Pareil !
idem
@thierry: Moi si a certaines heures le site (Frankfort) est introuvable…
Et moi qui croyait à un discret hommage à Bob l’éponge… Déçu je suis (enfin, presque) ;-)
Plus sérieusement, bon courage !
Pierre, qu’entends tu par « mieux gérer le site » ?
bon courage
@Laurent Simon: En gros, Le site est en cache et passe par un CDN mais les bons plans sont mis à jour en temps réel. Donc ils ne sont pas « cachés » et cela pose un gros soucis de nombre de requêtes qui explosent les capacités du serveur.
Il faut que je trouve une solution différente pour gérer cette partie du site.
Un site séparé?
@Piratu: J’y pense mais j’ai peur du temps imposé par la gestion de ce second site. L’intégration des deux dans minimachines est un bon garde fou. (Accessoirement, les bon plans étant le poumon économique du site, cela fait sens)
Si c’est un soucis de capacité du à la croissance organique naturel du nombre de visiteurs => augmenter les ressources (ça coute aussi plus cher).
Mais, comme disait plus haut un autre lecteur, bien vérifier avant si ce trafic est bien normal.
@Piratu: Je crois surtout que l’outil que j’utilise n’est pas calibré pour gérer autant de requêtes…
Pierre, as tu testé WP Rocket ? Je vois que tu as WP Fastest Cache d’actif, mais vu la tronche du code source de cette page, j’ai pas l’impression qu’il aide beaucoup.
Je n’ai pas testé WP Fastest Cache mais j’ai WP Rocket qui tourne sur plusieurs WP et les performances sont assez dingue, je pense que contrairement à ce que dit WP Fastest Cache sur sa page, WP Rocket est plus efficace.
Si tu ne l’as pas testé et que tu veux voir, j’ai une licence développeur, je peux te passer une copie pour tester.
Accessoirement pour les bon plan, le contenu annexe du blog doit pouvoir s’effacer au max, j’entends ce qui est dynamique et bouffe des ressources, le reste étant « cachable » et devrait consommer zéro. Je ne connais pas ta machine d’hébergement ni ta volumétrie, mais c’est pas normal que tu ai autant de prob si tous ton trafic tombe toujours sur les mêmes quelques pages.
Tu peux me contacter par Email si tu veux en discuter. Mais je ne suis pas expert des sites à fort volumétrie non plus.
Bon courage Pierre.
Le créateur de Bob l’éponge (caaaaaaaarrrrééééééée) est décédé récemment, tout Bikini Bottom est très triste.
Tiens bon la barre Capitaine !
Bon courage
Ouf, j’ai cru que devant le drame de la mort du père de Bob l’éponge, tu jetais la tienne.
Bon courage
Tu connais Wpserveur ?
https://www.wpserveur.net/tarifs-hebergement-wordpress/
Ils sont spécialisé en hébergement WordPress, peut être que ça vaudrait le coup de les contacter pour calibrer un hébergement qui ferais le travail et développer un plugin pour qu’il soit bien optimisé pour gérer du gros volume.
@Brice B.: Je teste WP Rocket :)
@Jean-Baptiste: Mon hébergement n’est pas en cause.
@Toureiffel2001 et @ElendilDrac01: C’était bien un hommage oui…
Salur, je m’y connais pas trop en dev web, mais quand tu dis que les bons plans sont pas en cache, comment sont ils gérés ? Ça tape direct dans la DB ?
« les bons plans sont mis à jour en temps réel »: c’est peut-être effectivement le problème: il faut tout de même utiliser une solution de cache (sur l’application ou le serveur) pour ce type de données, avec une petite durée de vie (une minute par exemple) sinon la performance site sera très sensible aux pics de fréquentation: les requêtes s’accumulent, les utilisateurs s’impatientent et rechargent leur page-> c’est un cercle vicieux et le site peut finir par tomber.
Je connais pas très bien wordpress mais un peu le php. De mémoire il y a des solutions type ehcache, je ne sais pas si WordPress intègre ce type de modules
Autre solution à valider : utiliser une base de données NoSQL pour les bons plans, elles sont faites pour peu d’écritures et beaucoup de lecture
DynamoDB?
Ehcache=java, sur php c’est memcached. Et ça à l’air d’exister sur WordPress : https://www.siteground.com/tutorials/supercacher/wordpress-memcached/
Après je jure pas que c’est simple a mettre en place.
Pierre, tu es déjà chez Cloudflare, tu peux activer leur système de caching. Ca coute un peu d’oseille mais bon…
Sinon tu colles un Varnish devant. Ca reste souple, tu géres ca au niveau DNS.
Si tu as besoin d’aide, n’hésite pas. Je t’héberge gratuitement ton caching si ca permet d’avoir un flux RSS qui arrive instantanément ;)
Bon courage.
@dja: j’avais pas vu les premiers commentaires en fait.
Les bons plans, tu peux les mettre en cache par 10 minutes voir à la minute (je ne sais pas si le cache cloudflare peut gérer des régles aussi fines? sinon varnish le fait bien sûr)
Tu es sous Mysql derrière je suppose, tu as activé le log des slow requests? tu sais où ca coince?
Bon courage dans tous les cas, je sais que ces tests d’optimisation sont souvent galère.
C’est clair qu’il faut trouver une solution pour mettre du cache sur les bons plans. Peut-être avec un vidage de cache à chaque mise à jour ?
J’aurais bien voulu aider Pierre, mais je n’ai pas autant de connaissances techniques que ceux qui sont déjà cités ci-dessus. Je bricole un peu sur WP mais ça va pas loin.
Mais si jamais, j’ai deux serveurs virtuels ssd que je peux prêter…
De mon expérience pro : arrêtez de mettre des plugins pour tenter de réparer le moindre souci dans WordPress, bon nombre ne sont pas optimisés dès que la volumétrie augmente. Le CDN c’est bien pour le cache mais ça a un coût souvent au débit. En tous cas j’ai souvent vue ici ces derniers jours le CDN qui n’arrivait pas à joindre le serveur de destination (pitié ne faites pas F5 sans arrêt dans ces cas là!). Pour supporter la charge, je conseil un HAProxy comme load balancer en front et derrière une grappe de serveur (style on en ajoute un ou deux en période de Black Friday pour tenir la charge en abo d’un mois). Pour mettre à jour les différents serveurs en une fois : du Galera ou une réplication MySQL couplé avec Unison pour les fichiers (pour éviter d’entrer dans du gfs). Question coût avec des grappes serveurs Kimsufi ou SoYouStart (dsl pour la pub) on peut déjà faire un truc bien pour pas cher. je reste à dispo si besoin :-)
Eh ben, ça en fait des pistes a exploiter… Allez courage Pierre ;-) on va arrêter de s’énerver sur la touche F5 en attendant que ça reparte sur une des bonnes bases proposée ;-)
@Pierre
Pour WordPress il y a plusieurs plug-in de cache mais effectivement WPRocket est le plus connu malgré qu’il soit payant.
Pourquoi ne pa mettre en cache les bons plans parce que c’est justement celle là qu’il faut cacher et si MAJ il y a, relancer la synchro
bon courage
@Simoryl: à mon avis, le truc aussi, c’est pas cher justement.
parce que cloudflare, Online, c’est déjà fait de ce que je vois…
du coup, il faut du pro de chez pro
et moi, à part joomla…
mais ça semble de retour donc bon on croise les doigts
@Pierre il te faut mettre du cache en place, même avec une durée de vie courte (1 min) l’impact sur le nombre de requêtes sera significatif.
@Frou: petite précision, du cache de méthode comme le propose ehcahe et certainement memcached. Cela permet de cibler précisément les méthodes en charge de l’appel à la base de données.
Bonjour
Je n’y connais rien en WP et en cache, mais j’ai une question :
qu’est ce que cette photo d’illustration ?
Merci
@pierre : comme tu as pu le lire sur un de mes commentaires sur un autre billet, je suis Dev Web !
Par contre, pas du tout spécialiste WordPress… Désolé ;) mais je reste dispo si tu veux ;)
@Emmanuel: Une petite recherche Google sur l’image donne ce lien
=> https://www.thinkgeek.com/product/iljn/?pfm=HP_Carousel_SteamPoweredGamingCabinet_3
@StarDreamer: Ce boitier est juste super beau, il faut juste avoir la TV et l’intérieur qui va avec …!
soutien moral à Minimachines; en attente du retour des liens sponsorisés des bons plans pour un soutien directe.
Au passage, courage avec le site. Et le comptoir du hardware cherche un spécialiste minimachines, ça peut faire un revenu, non ? Et pourquoi pas une aide ou solution technique pour le site ?
@pierre
Pour limiter les requetes de refresh sur tes bonplans tu as :
-fixer leurs mise en cache a une valeur faible (genre 1minutes)
ou
-utiliser l’API du cdn pour invalider le cache (cache invalidation)
ou
– utiliser l’API pour mettre les données voulu directement (upload)
En tout cas si un jour tu revois l’architecture Minimachines … je ne saurais trop te conseiller d’abandonner tous les moteurs de sites dynamiques (créant le site à la volée à partir de scripts type PHP ou autre … type WordPress and co), pour switcher sur des générateurs statiques.
Le principe est simple, le workflow beaucoup plus souple et efficace : on écrit les pages « offline » (souvent en markdown, stockables sur un repository GIT ou autre), le générateur se charge de transformer les fichiers sources du blog en HTML (avec le bon template, les menus, les liens, etc.). Il ne reste ensuite plus qu’à publier les pages HTML sur le serveur. Tout le workflow est au besoin automatisable.
Les avantages sont nombreux :
– le site n’étant constitué dans sa publication que de fichiers statiques (HTML, CSS, png, …) la partie technique sur le serveur est incroyablement simple (un serveur apache ou lighthttp ou autre sans aucun module particulier)
– la sécurité est maximale (peu voire pas de failles de sécurité liées à un moteur de script, une version de PHP, une version de wordpress, … – seul le seveur apache ou caddy ou autre est exposé, pas le moteur PHP, pas de scripts d’admin (vu qu’il n’y en a pas), etc.)
– la tenue à la charge est maximale (tout est généré avant publication, ensuite le serveur ne fait que publier des pages HTML)
– enfin, et je trouve aussi que c’est un avantage énorme, tous les éventuels « problèmes » de génération / mise à jour du site se voient *en amont* et en déconnecté, et pas en live sur le site – même si la génération plante (c’est rare mais çà peut arriver), le site n’est jamais touché vu que tout se fait en amont. C’est également très simple à tester.
Le tenor du titre est HUGO (ultra rapide même avec beaucoup de billets à générer) https://gohugo.io/
Avec bien sûr pleins de fonctions adaptées pour faire un blog : gestion des sommaires, tags, méta-données, brouillons, etc.
A noter qu’il existe même un mécanisme type « mini-base de données » interne permettant :
– d’avoir des datas (par ex. dans un CSV, un fichier TOML, etc.)
– d’avoir un template pour injecter ces datas dans les pages HTML avec le layout que l’on veut (en piochant les différents champs pour les injecter comme on le souhaite)
… qui permettraient parfaitement de gérer la partie « bons plans » (qui serait (par ex.) dans un .CSV, et c’est tout : à chaque génération, une (ou plusieurs si on veut) pages seraient générées avec tous les bons plans – l’avantage étant bien sûr que çà deviendrait dès lors une simple page HTML au final, parfaitement indexable par google et publiable sur un CDN comme n’importe quelle autre page).
Perso’, je ne reviendrais pas en arrière et çà fait un bail que j’ai abandonné tout ce qui est dynamique pour ce genre de cas de figure.
Un des rares inconvénients est le moteur de commentaire : il faut forcément un moteur externe plugable en javascript (type « disqus » ou alternatives).
Evidemment, migrer un site avec beaucoup d’historiques représente un coût certain, dépendant notamment (outre le nombre d’articles) du format source (markdown ou non, etc.), mais c’est un ticket d’entrée à payer pour gagner ensuite du temps en exploitation à moyen terme.
@Dgango: Hugo est absolument génial. Je l’adore et j’utilise aussi. Mais je pense que, ce n’est pas vraiment adapté aux besoins de Pierre.
HTML, Markdown, TOML ou YAML, sans WYSIWYG, c’est quand même au raz des pâquerettes et ça ne permet pas tout. C’est parfait dans un environnement très technique, dans un environnement plus généraliste, ça peut rapidement devenir vite limitant.
Et, il y a beaucoup de services qu’un CMS rend (à l’aide de requêtes) qu’Hugo est bien incapable de rendre, malgré ses templates qui permettent déjà pas mal de choses.
Personnellement j’utilise les deux (CMS et Hugo), mais dans des contextes bien différents. Ils ne s’adressent pas aux mêmes populations et ne se recouvrent que partiellement en terme de fonctionnalités.
Ceci dit, si Hugo suffit et match avec l’ADN de l’utilisateur ciblé, je suis d’accord pour dire que c’est la meilleure solution qui soit.
Ben moi je n’y connais rien mais du coup je vais attendre de récupérer des liens affiliés pour passer commande.
Bon courage Pierre !
+1 Varnish
Hello
Il y a beaucoup de très bons conseils dans les commentaires, et connaissant « un peu » le soucis de Pierre, il n’est pas l’ordre de cache d’assets quelconques, ni de pages complètes, de ce coté tout est OK, Varnish fait son taff, mais d’un plugin qui génère une requête avec 7/8 jointures, et qui est rejoué systématiquement, malgré le cache de la base qui taillé largement pour gérer cela.
Et la sus nommée requête ne passe pas en slow, elle se stacke par paquet de 10 sur l’écriture des tables temporaires, et j’anticipe, oui c’est écrit dans un ramdisk :)
Une fois ce mystère résolu, tout ira mieux :)
@fabinou:
Salut,
Je me permets de proposer cette solution alors si tu as varnish:
——- cut
acl forPurge {
« localhost »;
}
sub vcl_recv {
if (req.http.X-Varnish-Drop == « 1 » && req.url ~ /mistermatos/ && client.ip ~ forPurge) {
set req.hash_always_miss = true;
}
/* et le reste en ttl forcé obligatoire … 5, 10, … minutes */
}
—— /cut
Et toutes les 1 ou 2 minutes, tu lances en cron une req http du server en tapant sur le 127.0.0.1 (sur le vhost https://www.minimachines.net) avec le header ‘X-Varnish-Drop: 1’ sur la page /mistermatos
Ca laisse les externes se faire servir tout le temps la version en cache, et il y a un refresh automatique qui se prend la lenteur du plugin en question sans que ca puisse saturer. Tu n’as plus qu’un vrai accés qui tape sur la DB toutes les 1 ou 2 minutes.
Le process est réplicable sur toutes les pages sensibles, le cher flux RSS par exemple ;-)
Bon courage encore.