Journal site de la flamme olympique aux tuileries

Posté par  . Licence CC By‑SA.
Étiquettes :
14
31
juil.
2024

Cher journal,

j'ai voulu aller voir la "flamme" [1] olympique et son ballon.

Pour ce faire, il fallait s'inscrire. Quel ne fut pas ma surprise qu'en 2024, pour un événement de ce style on ne sache toujours pas faire quelque chose qui marche.

Le site a été victime de son succès. Mais pas de file d'attente pour réguler le trafic. A la place un site lent et des timeout réseau à la place.
La page d'inscription est lourde 50MB de ressources dont une partie va être rechargé à chaque rafraîchissement.

Quand ça fonctionne on peut remplir un formulaire, mais plus rien ne se passe. En sortant les outils de dev, on voit qu'une requête est faite pour avoir un calendrier est fait. Mais ça timeout en 504 et aucun message sur la page.
Et une fois le calendrier obtenu, il y a le même système pour avoir les horaires.

Sans les outils de debug pour savoir quand il faut faire des retry, c'est inutilisable. Je ne sais pas comment les gens normaux ont fait.

Une fois l'heure choisie, une requête est envoyé pour faire la réservation. Cette requête part aussi en erreur. Pas possible de faire un retry depuis l'interface web (ui est dans les choux et il faut repartir à 0). Mais on peut faire du replay depuis les outils de debug.
Et au bout d'un moment ça passe. En fait même en 504, certaines requêtes ont abouti sur le serveur et fait une résa. Je me suis retrouvé avec plusieurs résa validées.

Le site n'est pas robuste à la surcharge.
C'est très facile à scripter la résa en rejouant la requête finale. Et ça saute même les protections de plusieurs résa sur un même mail !

Voila, ils n'auront pas la médaille d'or du meilleur site des JO 2024.

Ça n'existe pas des frameworks open source de résa où toute la partie complexe (file d'attente, gestion propre des erreurs, …) est déjà faite ?

En tout cas, là c'est du made in france. Avec des commentaire en français, du code javascript commenté (dont des trucs de debug).

[1] la flamme est dans une petite lanterne. Sur le ballon c'est led + brumisateur, mais ça un petit effet

[2]
// Mettre à jour le compte à rebours toutes les secondes

  • # correction

    Posté par  . Évalué à 3.

    s/au tuilerie/aux tuileries/

    https://fr.wikipedia.org/wiki/Jardin_des_Tuileries

    • [^] # Re: correction

      Posté par  (Mastodon) . Évalué à 4.

      Corrigé, merci.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Solidité

    Posté par  . Évalué à 3.

    Ça n'existe pas des frameworks open source de résa où toute la partie complexe (file d'attente, gestion propre des erreurs, …) est déjà faite ?

    Ça n'est pas si simple. Pour tenir ce genre d'échelle, ce n'est pas qu'une question de code. Ton déploiement doit aussi être correct et il faut que ton code et ton déploiement bénéficie l'un de l'autre.

    Par exemple à mon avis, si je voulais faire ça j’essaierais de partir sur un fonctionnement très asynchrone avec un brocker (pas en mémoire) de messages qui représentera ta requête et on t'enverrais par mail la confirmation de ta réservation. Donc potentiellement je te demanderais d'indiquer 3 ou 4 horaires qui te conviendrais et le bousin sélectionne ce qui est encore possible. En plus on doit pouvoir tenter de faire une stat sur le temps de traitement en fonction de la taille de la file dans le message et te dire qu'on va te confirmer d'ici quelques minutes.

    Pour info je connais une asso (techniquement j'ai oublié le nom) qui a tenté de ce lancer dans ce genre de service proposé un site de vente de place pour d'autres association et ça a bien foiré dès que c'est monté un peu en charge (de ce qu'on m'a dit il était impossible de corréler les factures, les paiements et les places réservées, il y avait genre x factures, y paiement et z places réservées et aucun des trois ne correspondait et bien sûr il y a eu de la sur réservation - sans qu'il s'agisse d'une attaque ni que ce soit pour un concert d'Elvis Presley).

    Après ça n'enlève pas que de ce que tu décris le site a quand même l'air de bien mal marcher

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Solidité

      Posté par  . Évalué à 0.

      et si tout passait par e-mail ? c'est plus facile de traiter des fichier textes et d'en envoyer que de le faire de manière cool en live, avec des pages de 50Mo

      on préviens si horaire pas dispos vous aurez le prochain horaire disponible

      avec un calendrier qui lui est en live, sur une page de 100Mo et permet de voir les réservation possible en temps réel

      ca empêchera pas les sur réservation avec plusieurs mail, ca tiendrait potentiellement la charge :/

      sinon, on fait remplir un fichier texte prérempli , on leur demande de le mettre sur un serveur avec un ftp, et la il n'y aura plus personne \o/ pour le faire

      • [^] # Re: Solidité

        Posté par  . Évalué à 2.

        Ton mail a un format facilement parssable pour trouver la date en question ou il est écrit en langage naturel et doit être lu par un humain ou une IA ?

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Solidité

          Posté par  (site web personnel) . Évalué à 5. Dernière modification le 01 août 2024 à 11:44.

          le mail :

          • pas de garantie d'acheminement
          • pas de garantie d'intégrité (à moins d'utiliser un système de signature)

          pas la meilleure idée du monde :/

          Au moins un broker peut le faire et tu choisis ton format de messages (XML à l'ancienne, JSON en plus moderne, on évitera CSV :p j'aimais bien ASN.1 il y a pleins de bibliothèques pour le traiter depuis le siècle dernier)

          Puis bon, une bonne API ça tient la route de nos jours, avec des requêtes/réponses de 1 ko à 100 ko pour être efficace (voire jusqu'à 2-4 Mo si on veut conserver des infos de session :/)

    • [^] # Re: Solidité

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Faut arrêter avec cette légende de la mise à l’échelle.

      Ce site doit recevoir, 100.000 personnes par jour. Ça fait, en moyenne, moins de deux personnes par seconde.

      Bon, on imagine des pics avec jusque 10 personnes par seconde : n’importe quel raspberry pi peut soutenir cette charge. Donc si on multiplie même par 100 les pics, on peut imaginer qu’un serveur moderne supporte ça sans problème.

      Sur un site bien codé.

      Sauf si c’est codé avec les pieds et que chaque personne qui se connecte réalise en fait plusieurs centaines de requêtes qui vont vers des bases de données avec des verrous.

      C’est juste qu’on est vraiment devenus tellement nuls qu’on réfléchit à la mise à l’échelle en imaginant à l’avance que le truc va être hyper lourd et codé avec les pieds parce que "tout le monde fait comme ça".

      Et vous savez quoi ? La mise à l’échelle rend les choses tellement complexes que le code devient de plus en plus lourd et que ça empire la charge.

      Mais bon, c’est tout bénéf pour Microsoft Azur et Amazon S3 qui facturent à l’utilisation des ressources.

      Ptêtre que ce n’est pas un hasard…

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Solidité

        Posté par  . Évalué à 9.

        Je te l'ai dis je l'ai expérimenté sur une conférence de 600 personnes hors de Paris.

        J'ai passé ces 6 dernières années à voir ce que ça donne les comportements des spectateurs du football lors du coup d'envoi d'un match du PSG (j'aime pas le foot c'est pas une appréciation de l'équipe elle est simplement bien plus suivie que n'importe quelle autre en France).

        Sur un site bien codé.

        Vraiment je te laisse essayer d'avoir un jour affaire à ce genre de choses avec "un site bien codé". J'ai personnellement vu haproxy (ou plutôt le couple haproxy openssl) à genoux pour beaucoup moins que ça (avant même que du code autre soit impliqué sur du barre métal bien de chez nous avec une connexion d'opérateur bien dimensionnée).

        La charge c'est un truc qu'on prend de haut quand on s'est pas encore pété les dents dessus. Ce n'est pas un reproche ça a était mon cas et on apprend que l'on ne gère jamais la charge, mais qu'on a prévu pour gérer une charge donnée.

        Ton commentaire n'est qu'une série d'a priori. Je te souhaite un jour de mettre au défit ces a priori avec une prod un peu chargée, c'est très enrichissant.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Solidité

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Je dois préciser que mes connaissances sur le sujet datent un peu car cela fait 10 ans que je n’héberge plus rien. Mais j’ai lu quelques articles dans la communauté admin sys qui vont exactement dans mon sens.

          J’ai quand même auto-hébergé mon blog pendant une décennie. Je me suis pris certains afflux monstrueux (avec des pointes à 100.000 visiteurs uniques sur 2 heures). Mon blog tournait à l’époque sur Wordpress : et bien ça a tenu sans problème particulier autre qu’une surcharge CPU durant ces quelques heures. (si mes souvenirs sont bons, j’avais quand même pas mal chipoté avec monit pour tuer régulièrement les processus apache qui ne répondaient plus)

          Après, je n’avais pas de plugins partout, je tentais déjà à l’époque de simplifier mon code et ma gestion serveur en minimisant le nombre de process.

          J’ai fait beaucoup d’erreurs. J’ai eu deux fois un serveur que je gérais piraté (un utilisateur qui avait un logiciel php non à jour dans les deux cas). J’ai eu des gros soucis dans ma gestion de backup, dans ma gestion du matériel. J’en ai compris que l’admin serveur c’est hyper difficile, hyper exigeant.

          Mais y’a un truc que j’ai appris : la mise à l’échelle et l’optimisation, ça se pense dans le code de l’appli web. Et une appli web mal foutue peut metter à genoux n’importe quelle infrastructure avec quelques dizaines de requêtes.

          La mise à l’échelle au niveau des serveurs, c’est un truc hyper compliqué qui peut souvent faire pire que mieux. Un truc que j’ai vu, par exemple : c’est des serveurs redondants qui, à chaque requête, communiquaient entre eux. Du coup, chaque serveur se prenait deux fois plus de requêtes que s’il n’y avait pas eu de de redondance. Ou alors une utilisation foireuse des CDN qui fait que tout le réseau plante si soit le serveur soit le CDN sont surchargés (ça semble être la norme de ce que je vois).

          De mon expérience, je soupçonne que le site des JO soit, comme tout site moderne, codé avec les pieds par la boîte du fils du cousin d’un patron du CIO. Que ce code a ensuite été balancé sur un docker car personne ne sait l’installer. On a donné ce docker à un admin sys en stage en lui disant de scaler, alors il a googlé "docker + amason S3", déployer le machin, mit le budget pour laisser Amazon faire la mise à l’échelle sauf que le docker, au moment de la commande, appelle un serveur SQL qui lui est dans un data center et qui sert de goulot d’étranglement mais personne ne sait comment ça fonctionne. Et ça a été facturé 10 millions au CIO.

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: Solidité

            Posté par  (Mastodon) . Évalué à 8. Dernière modification le 01 août 2024 à 13:42.

            C'est quoi le rapport entre docker et amazon s3 ?

            Je suis d'accord sur le fond de ton commentaire que l'archi, l'optimisation du code et des requêtes est primordiale mais j'ai l'impression que tu ne sais même pas de quoi tu parles alors cela dessert ton propos.

            Ce que je sais, c'est qu'une guichetterie en ligne de concert sert probablement bien plus de requêtes en pic que celui de la flamme olympique. Alors certaines sont aussi absolument faites avec les pieds aussi et ne tiennent pas bien la charge à l'annonce du concert d'une superstar ou d'un festival de renom mais d'autres ronronnent.

            J'ai aussi travaillé pour une banque qui était spécialisée dans le trading en ligne. Ben question charge qui explose ça se pose aussi, surtout en cas d'évênements particulier, comme des avions qui se crashent dans des tours jumelles, où en cas de crash boursier 2008. Ben vous savez quoi, c'était quand même bien architecturé, on avait des super DBA qui analysaient les requêtes écrites par les developpeurs, les conseillaient sur les requêtes, l'indexation, on faisait des tests de charge, on faisait des comparaison entre de la mise à l'échelle horizontale (plus de machine) ou avoir des machines plus grosses, on avait fait la comparaison entre pleins de petits services éparpillés avec pleins de connections réseau, une appli monolithique ou quelque chose entre les deux, on comparait des architectures CPU, etc etc. Et bien quand on a eu des grosses montées en charge, on le voyait bien sur les courbes CPU de notre monitoring et sur la charge sur la clim. Mais les applis, elles répondaient. Donc oui c'est possible et ça a un coût, tant en terme d'infra que humain parce que le développement, ça prend plus de temps quand on doit réfléchir à ce que l'on fait, qu'on veut se donner les moyens de tester ou pas.

            Je crois surtout que dans ce genre de cas, on cherche tellement à limiter les coûts que ça part en prod si de simple tests montre que ça marche et qu'il n'y a pas vraiment de réflexion sur l'architecture.

            • [^] # Re: Solidité

              Posté par  (site web personnel) . Évalué à 8.

              Sauf que là on parle d'une boutique qui aura servi 1 seul jour.
              Le temps de vendre l'ensemble des billets entre le vendredi minuit et le samedi midi (100 000 je crois).
              Est-ce comparable avec un outil de banque qui va servir tous les jours pendant des années? Quel différence de coût et de moyens mis dans ces deux infras ? Quels retours sur investissement ?

              Le but du site : vendre les tickets. C'est atteint, ils sont tous partis. Il y a des décus ? Oui sans doute : ceux qui ont eu des erreurs, ceux qui sont arrivés trop tard, ceux qui habitent trop loin et qui aurait aimé voir cette vasque.

              Alors oui on peut faire des choses parfaites, dimensionner le tout suffisamment, faire le pari que dès le lendemain 200 000 personnes se déchireront les billets ou peut être que 500, …, optimiser tout au petits oignons, mais dans quel but ?

              • [^] # Re: Solidité

                Posté par  . Évalué à 5.

                Point de vue original et pertinent merci

                "Si tous les cons volaient, il ferait nuit" F. Dard

              • [^] # Re: Solidité

                Posté par  . Évalué à 7.

                En fait c'est typiquement le cas où tu ne fais pas de site. Tu achète les service d'une boite qui sait faire ça. Parce que tu ne sait pas quelle sera ta charge, tu n'a aucun moyen de savoir si tu va prendre 3 fois le nombre de billets que tu as ou si tu va prendre un DDOS parce que les JO, parce que ça amuse un script kiddy, parce qu'un pays veut faire chier le monde,… Ça existe, tu as des gens qui savent vendre des billets de concert pour Taylor Swift ou Beyoncé, ils n'auront aucun mal à gérer ton flux supplémentaire. Potentiellement tu peux même leur acheter une prestation très courte (genre laisser le site en ligne quelques heures/jours seulement).

                Bien coder c'est aussi savoir quand ne pas coder et utiliser une bibliothèque ou un service.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Solidité

              Posté par  . Évalué à 2.

              Je crois surtout que dans ce genre de cas, on cherche tellement à limiter les coûts que ça part en prod si de simple tests montre que ça marche et qu'il n'y a pas vraiment de réflexion sur l'architecture.

              C'est possible, mais je pense que même si ce n'était pas le cas ça aurait donné la même chose. Parce que gérer de la charge que tu ne connais pas et plus ou moins impossible. L'estimation que tu fais pour tenter de connaître ce que tu es capable de prendre en charge est totalement au doigt mouillé.

              Les JO c'est toujours l'exemple du truc qui est à la fois une charge intensive et tellement ponctuelle que tu n'a que peut de chances de gérer à moins d'oversizer "au cas où" et si tu fait de quoi tenir une grosse attaque DDOS et que tu l'a pas on te dira que tu jette l'argent par les fenêtres1.

              1. c'est le cas avec Roslyne Bachelot pour les vaccins contre le H1N1. C'était pas parfait, mais c'était ambitieux et comme ça n'a finalement pas était une pandémie elle en a pris pleins la tête. 10 ans plus tard on pleurait de ne pas avoir une politique aussi ambitieuses. ↩

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Solidité

                Posté par  (Mastodon) . Évalué à 3.

                C'est possible, mais je pense que même si ce n'était pas le cas ça aurait donné la même chose. Parce que gérer de la charge que tu ne connais pas et plus ou moins impossible.

                Alors chaque pays a ses particularités et cultures, mais j'ose imaginer que quand tu organises les JO, tu vas visiter les éditions précédentes, leurs organisateurs et poser les bonnes questions. T'as pas forcément les chiffres exacts mais des tendances relativement réalistes.

                • [^] # Re: Solidité

                  Posté par  . Évalué à 1.

                  Dans quelle édition des JO tu as des billets pour aller voir spécifiquement la flamme olympique ? Et pas des billets pour aller au stade d'athlétisme dans le quel il se trouve qu'il y a la flamme ?

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Solidité

                    Posté par  (Mastodon) . Évalué à 3.

                    Ben peut-être que l'idée à la con était là, j'en sais rien. Et pourquoi faire un site différent pour acheter un billet pour voir la flemme et pas utiliser le même qui a été utilisé pour acheter un billet pour une épreuve sportive?

                  • [^] # Re: Solidité

                    Posté par  . Évalué à 0.

                    ceux en Corée du nord ?

      • [^] # Re: Solidité

        Posté par  (site web personnel) . Évalué à 4.

        Ça fait, en moyenne, moins de deux personnes par seconde.

        tu ne fais pas la moyenne sur les 86400 sec de la journée mais plutôt sur les pics (ce que tu as pris en compte ensuite) : généralement 10h à 11h et 15h à 16h puis 21h à 22h, soit plutôt 9 requêtes/sec sur ces 3 heures à multiplier par le nombre de requêtes nécessaires pour finaliser la transaction.

        mais oui, je rejoins ton analyse — même sans dire qu'un RPi suffirait — tout serveur correct devrait tenir la route si l'architecture applicative/logicielle ne fait pas tout pour enterrer l'architecture technique/système /o\ forcément, avec des pages de 50 Mo tu vas en plus tout de même écrouler ton réseau… (même avec des CDN que — si tu en es là — tu ne sollicitera pas correctement non plus, hormis pour les pubs bling bling avec des vidéos de logo en flamme qui tourne _o/ en 1080p :p)

        • [^] # Re: Solidité

          Posté par  . Évalué à 2.

          du coup personne de motivé de faire un petit poc à l'arrache ? :)

          ça me tente beaucoup, j'ai pas mal de projet en cours et n'ayant aucune connaissance sur le sujet ce sera à 95% codé avec chatgpt, oh wait ! comme le site actuelle !

  • # Écoterrorisme

    Posté par  (Mastodon) . Évalué à 7.

    La page d'inscription est lourde 50MB de ressources dont une partie va être rechargé à chaque rafraîchissement.

    Pour une pseudo-flamme qui consomme trois mètres cube d'eau à l'heure, ça me semble cohérent.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.