additional fixes

_posts/2024-04-27-capa-web-deuxfleurs.md

@@ -1,6 +1,6 @@
 ---
 layout: post
-title: Capacité web Deuxfleurs
+title: Quel est la capacité de Deuxfleurs ?
 date: 2024-04-27
 status: published
 sitemap: true
@@ -22,6 +22,9 @@ En terme de stockage, on a 4To de stockage à Lille, 1.5To à Bruxelles, 3To à
 Avec notre politique de 200Mo/site max, ça fait quand même déjà une capacité de 7 500 sites webs. On montr à 30 000 sites webs si on considère 50Mo (la taille réservée à la création du site, avant l'augmentation du quota). Si on passe à Bruxelles à 3To pour "rattraper" les autres sites, on double le nombre de sites web hébergeables. De plus, aujourd'hui on trouve des disques durs 2.5" à 4To, ce qui veut dire qu'on pourrait passer entre 8To et 15To par zone géographique sans changer radicalement notre infrastructure (même boitier, meme enveloppe de consommation electrique, etc.). Dans ce cas hypothétique, on dépasse les 100 000 sites webs hébergeables. Bien sûr à chaque fois, c'est en supposant qu'on héberge que des sites webs : mais on peut diviser par 2 les chiffres, et se dire qu'on alloue le reste aux autres services, et ça reste étourdissant !
 
 Se pose maintenant la question de la montée en charge, combien de requêtes/secondes on peut traiter. Aujourd'hui on a un ~10 req/sec continu (majoritairement du à Matrix et Sogo, des protocoles de chat & email respectivement au dessus de HTTP qui font du polling, c'est très en dessous côté hébergement web garage) qui n'ébranle pas franchement nos serveurs. On va donc faire du *scalability testing* pour voir jusqu'où on peut monter. Il faut savoir que le pire cas pour nous, c'est quand un site web devient populaire d'un seul coup, et que tout le monde s'y connecte en même temps avec un cache froid, par exemple parce qu'un tweet devient viral ou des notifications push sur mobile envoyés par une application. On va donc prendre ce cas pour notre test.
+
+*Notez que pour les notifications mobiles, plutôt que de déployer d'avantages de serveurs pour gérer le pic de trafic, il est plus avisé d'échelonner leur envoi auprès des utilisateurs. C'est à dire envoyer un premier lot de notifications à 10% des utilisateurs, attendre 20 minutes, envoyer le 2nd lot, etc. Et oui, c'est aussi bête que ça parfois...*
+
 Notre cobaye sera ce propre blog, et plus exactement sa page d'accueil et ses 9 ressources à charger. J'utilise l'outil [k6](https://k6.io/) pour ce test qui n'a pas vocation à être exhaustif, pour info voici le script de test :
 
 ```js
@@ -48,5 +51,5 @@ Mon test n'est pas du tout exhaustif ou représentatif de tout le web statique -
 
 À noter aussi qu'on a pas passé beaucoup de temps à penser l'optimisation des ressources de Deuxfleurs, on pourrait probablement avoir des gains avec de petites modifications. Par exemple en utilisant les spécificités d'IPv6 qui permettent de mettre plusieurs load balancers par zones géographique, ou en favorisant le chiffrement ChaCha20-Poly1305 qui est plus rapide que AES sur les CPU qui n'ont pas d'accélération matérielle comme les notres. Côté matériel, on pourrait s'assurer qu'on a du lien gigabit partout (et donc faire la chasse au 100Mb qui trainerait).
 
-Et pour terminer avec une conclusion provocante : avec 10 req/sec, rarement plus de 5Mb/s de trafic sortant, et 250 sites webs hébergés, c'est respectivement 1% du budget requête, 2.5% de la bande passante, et 3% du budget stockage qui est actuellement utilisé sur Deuxfleurs.
+Et pour terminer, une conclusion provocante : avec 10 req/sec, rarement plus de 5Mb/s de trafic sortant, et 250 sites webs hébergés, c'est respectivement 1% du budget requête, 2.5% de la bande passante, et 3% du budget stockage qui est actuellement utilisé sur Deuxfleurs.