Que se passe t-il sur minimachines ?

Je ne suis pas en vacances, c’est le serveur qui me met au chômage technique. Depuis quelques jours, vous avez probablement rencontré de multiples perturbations sur le site, je vous explique un peu où j’en suis.

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 faire1. 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.

Soutenez Minimachines, partagez le !

Notes :

  1. Ce billet est également une sorte de test

Pas de Pub
55 commentaires sur ce sujet.
  • 29 novembre 2018 - 15 h 37 min

    Bon courage Pierre. On saura être patient !

    Répondre
  • 29 novembre 2018 - 15 h 46 min

    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?

    Répondre
  • 29 novembre 2018 - 15 h 48 min

    je n’ai rencontré aucun problème, je ne m’étais rendu compte de rien. Donc tout n’est pas noir

    Répondre
  • 29 novembre 2018 - 15 h 49 min
  • 29 novembre 2018 - 15 h 51 min

    idem

    Répondre
  • Xo7
    29 novembre 2018 - 15 h 54 min

    @thierry: Moi si a certaines heures le site (Frankfort) est introuvable…

    Répondre
  • 29 novembre 2018 - 16 h 03 min

    Et moi qui croyait à un discret hommage à Bob l’éponge… Déçu je suis (enfin, presque) ;-)

    Plus sérieusement, bon courage !

    Répondre
  • 29 novembre 2018 - 16 h 20 min

    Pierre, qu’entends tu par “mieux gérer le site” ?

    Répondre
  • 29 novembre 2018 - 16 h 23 min

    bon courage

    Répondre
  • 29 novembre 2018 - 16 h 24 min

    @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.

    Répondre
  • 29 novembre 2018 - 16 h 34 min

    Un site séparé?

    Répondre
  • 29 novembre 2018 - 16 h 48 min

    @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)

    Répondre
  • 29 novembre 2018 - 16 h 51 min

    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.

    Répondre
  • 29 novembre 2018 - 17 h 00 min

    @Piratu: Je crois surtout que l’outil que j’utilise n’est pas calibré pour gérer autant de requêtes…

    Répondre
  • 29 novembre 2018 - 17 h 13 min

    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.

    Répondre
  • 29 novembre 2018 - 17 h 30 min

    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.

    Répondre
  • 29 novembre 2018 - 17 h 58 min

    Tiens bon la barre Capitaine !

    Bon courage

    Répondre
  • 29 novembre 2018 - 18 h 34 min

    Ouf, j’ai cru que devant le drame de la mort du père de Bob l’éponge, tu jetais la tienne.
    Bon courage

    Répondre
  • 29 novembre 2018 - 18 h 52 min

    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.

    Répondre
  • 29 novembre 2018 - 19 h 16 min
  • 29 novembre 2018 - 19 h 17 min
  • 29 novembre 2018 - 19 h 23 min

    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 ?

    Répondre
  • 29 novembre 2018 - 19 h 56 min

    « 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

    Répondre
  • 29 novembre 2018 - 20 h 16 min

    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

    Répondre
  • 29 novembre 2018 - 20 h 46 min

    DynamoDB?

    Répondre
  • 29 novembre 2018 - 20 h 46 min
  • dja
    29 novembre 2018 - 21 h 03 min

    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.

    Répondre
  • dja
    29 novembre 2018 - 21 h 11 min

    @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?

    Répondre
  • FQ
    29 novembre 2018 - 21 h 44 min

    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 ?

    Répondre
  • 29 novembre 2018 - 21 h 48 min

    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…

    Répondre
  • 29 novembre 2018 - 23 h 15 min

    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 :-)

    Répondre
  • 29 novembre 2018 - 23 h 39 min

    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 ;-)

    Répondre
  • 30 novembre 2018 - 0 h 05 min

    @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

    Répondre
  • 30 novembre 2018 - 0 h 36 min

    bon courage

    Répondre
  • 30 novembre 2018 - 0 h 57 min

    @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

    Répondre
  • 30 novembre 2018 - 7 h 54 min

    @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.

    Répondre
  • 30 novembre 2018 - 8 h 24 min

    @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.

    Répondre
  • 30 novembre 2018 - 9 h 22 min

    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

    Répondre
  • 30 novembre 2018 - 9 h 24 min

    @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 ;)

    Répondre
  • 30 novembre 2018 - 10 h 11 min
  • 30 novembre 2018 - 10 h 14 min

    @StarDreamer: Ce boitier est juste super beau, il faut juste avoir la TV et l’intérieur qui va avec …!

    Répondre
  • 30 novembre 2018 - 13 h 05 min

    soutien moral à Minimachines; en attente du retour des liens sponsorisés des bons plans pour un soutien directe.

    Répondre
  • 30 novembre 2018 - 13 h 13 min

    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 ?

    Répondre
  • 30 novembre 2018 - 15 h 22 min

    @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)

    Répondre
  • 30 novembre 2018 - 16 h 06 min

    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.

    Répondre
  • 30 novembre 2018 - 17 h 18 min

    @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.

    Répondre
  • 30 novembre 2018 - 18 h 30 min

    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 !

    Répondre
  • 30 novembre 2018 - 18 h 39 min

    +1 Varnish

    Répondre
  • 30 novembre 2018 - 19 h 05 min

    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 :)

    Répondre
  • dja
    30 novembre 2018 - 21 h 33 min

    @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.

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *