Avec ces paramètres, l’UX était meilleure. Oui, il y a eu plusieurs « goulots d’étranglement » et une série de réponses 429 ont été enregistrées dans l’inspecteur de Chrome. La charge CPU était faible. Mais après tout, c’était un jeu à domicile plutôt calme (de nombreux membres actifs étaient sur place, sans chatter).
Je ne peux pas nommer les réglages à modifier, mais, selon mon expérience plutôt subjective :
La fonctionnalité de code reste trop protectrice vis-à-vis de la charge du serveur. Peut-être qu’un niveau de stress serveur légèrement plus élevé pourrait être autorisé.
Lorsque le client réduit sa fréquence, le délai est trop long du point de vue de l’UX. Le jeu continue et beaucoup de choses peuvent se produire en une minute. Le chat se désynchronise, les gens faisant référence à différents événements du jeu. (Cela s’ajoute au problème des différents délais entre le temps réel, la télévision par câble, l’IPTV et le tampon de Chromecast de 20 secondes, etc.)
Les utilisateurs ne voient que le chat bloqué, sans aucune indication que le site est toujours en ligne et actif. Ils sont plus enclins à rafraîchir la page ou à faire d’autres choses, ce qui ajoute à la charge élevée.
Juste pour écarter certaines causes, j’ai mis à niveau le serveur vers 8 cœurs vCPU et 32 Go de RAM. J’ai configuré les tampons de la base de données à 16 Go et les processus Unicorn à 16. Les autres réglages sont revenus aux valeurs par défaut.
Malheureusement, la mise à niveau n’a pas apporté grand-chose. Les discussions rapides se figent constamment, même avec une activité médiocre.
Les performances sont lamentables ces derniers temps. Je suppose que je dois commencer à examiner Prometheus, etc. Je suis à 95 % certain que les performances du logiciel se sont sérieusement dégradées depuis la version 2.3.
Le commentaire du frère @Iceman a été largement ignoré en septembre. Il rapporte que les goulots d’étranglement se produisent quels que soient les matériels qu’il utilise ?
Je soupçonne que vous rencontrez un goulot d’étranglement avec Redis, mais comme je l’ai dit à de nombreuses reprises, nous ne pouvons en être certains que si vous collectez ces statistiques. Sans cela, nous pourrions tout aussi bien recourir à l’astrologie.
Si mon soupçon est justifié, cela expliquera également pourquoi ajouter plus de cœurs lents et de RAM ne change rien au problème. Puisque Redis est monothreadé, vous ne pouvez le faire évoluer qu’en utilisant des cœurs haute performance.
Nous publierons une nouvelle image avec la version finale de 2.6 d’ici la fin du mois, qui inclura Redis 6 et de nouvelles variables app.yml pour en tirer pleinement parti. Faites-moi savoir si vous souhaitez le tester plus tôt ; je peux vous fournir les instructions nécessaires.
Je viens de remarquer cela sur un sujet fermé. @codinghorror - c’est incorrect. Voici ce que l’utilisateur final rencontre réellement dans une situation de forte charge :
Une notification indiquant qu’il a été déconnecté
Il est redirigé vers la page d’accueil du site
La page d’accueil affiche une bannière indiquant une forte charge
Cependant, l’utilisateur n’est pas vraiment déconnecté. En général, lorsqu’il revient au sujet actif, le site fonctionne normalement.
Encore une fois, aucun de nos clients ne signale ce comportement (sur des milliers d’entre eux, dont beaucoup ont un trafic bien plus élevé que votre site). Par conséquent, toute discussion supplémentaire à ce stade est pratiquement inutile : nous n’avons aucune visibilité sur la configuration particulière ou les problèmes de performance matérielle que vous pourriez rencontrer de votre côté.
À l’avenir, nous espérons que cela changera et que nous aurons une meilleure visibilité sur le problème réel.
Je ne faisais que signaler ce qui se passe réellement au niveau de l’interface utilisateur et de l’expérience utilisateur en cas de forte charge. Rien de plus.
Vous avez très probablement raison. C’est bien Redis. La nouvelle image de base améliore la situation, mais nous dépassons désormais les capacités des serveurs.
Peut-être, mais ce n’est pas ainsi que cela fonctionne en réalité. Je l’ai reproduit il y a une minute.
Solution : écrivez un code plus léger et plus efficace
Donc, si Redis est le goulot d’étranglement, comment procéderiez-vous pour une mise à l’échelle horizontale ?
Je continue de me demander ce qui a changé depuis la dernière saison. Je ne vois pas vraiment de croissance organique ni d’augmentation de la popularité du chat en jeu. Pourtant, notre capacité à servir a considérablement diminué et elle sature même lors des parties les plus calmes.
Tant que vous ne pourrez pas collecter des métriques sur votre instance historique de Discourse et les comparer aux métriques de votre installation actuelle, tout en conservant exactement le même matériel, ce mystère restera entier.
La différence pourrait simplement provenir du fait que votre fournisseur de VPS vous a migré d’une machine physique à une autre, que vous avez un « voisin bruyant », ou que votre VPS héberge désormais en moyenne 17 services au lieu de 13 par machine.
Veuillez ne pas spéculer sur le fait de soulever le problème auprès du fournisseur VPS. UpCloud est l’un des meilleurs du marché et ils ont vérifié leur côté pour détecter toute anomalie. Ils font de la publicité sur notre site, et ce ne serait pas très bon pour l’image de notre site s’il connaissait des ralentissements
Cependant, il n’y a pas de données historiques, et pour être honnête, je ne prêtais pas autant attention que cela car tout fonctionnait parfaitement, jusqu’aux premiers matchs d’exhibition en août. Bien sûr, les comportements humains ont changé grâce à la COVID, et qui sait quoi d’autre. Je ne vois rien dans les métriques de notre site ou de notre serveur, cependant.
Mais c’est un excellent matériel de test. J’ai simplement fourni à @riking quelques captures d’écran de ce qui se passe lorsque la surcharge du serveur s’active. Je suppose que vous ne le voyez pas aussi souvent que cela.
Notez que personne n’est en désaccord avec vous — nous soulignons simplement qu’un médecin ne peut faire que ce qu’il peut pour diagnostiquer un patient lorsqu’il est limité à l’examiner via une caméra vidéo sur Internet..
Je voulais simplement préciser que c’était exactement ce que j’ai vécu lors de la configuration initiale de mon site (ce n’est donc pas spécifique à votre site).
Voici un sujet que j’ai créé à l’époque à ce sujet :
C’est ce qui m’a poussé à passer à des options CPU/mémoire plus élevées, comme décrit ici :
Malheureusement, je n’ai pas encore eu l’occasion de migrer correctement vers Hetzner depuis Digital Ocean comme je l’avais prévu (j’ai commencé un nouveau travail). Mais je le ferai dès que possible ce mois-ci.
L’expérience utilisateur, qu’il s’agisse d’être expulsé du fil de discussion ou de rester dedans (avec le message de déconnexion), semblait dépendre de la charge. (davantage d’utilisateurs ont été redirigés vers l’index du site après un but marqué).
Je ne possède pas suffisamment de connaissances techniques pour être utile, mais il me semblait important de signaler qu’un site sportif présentant des pics de comportement similaire à celui d’un chat rencontre des problèmes similaires. Le mien (plus petit et plus récent) a été résolu en effectuant une nouvelle mise à niveau du serveur.
Si vous souhaitez disposer de données pour prendre des décisions concernant le diagnostic des problèmes futurs, vous pouvez installer le plugin d’exportateur Prometheus pour Discourse.
Installation d’un nouvel environnement à 2 conteneurs sur 2 serveurs VPS (web_only, data).
Étonnamment (pour moi), le serveur web_only est en surcharge, tandis que le serveur data est relativement peu sollicité. Tous deux exécutent un plan UpCloud.com de 4 cœurs vCPU et 8 Go de RAM.
Mise à niveau du serveur web_only vers un plan UpCloud.com de 6 cœurs vCPU et 16 Go de RAM. Augmentation du nombre d’Unicorns à 18.
Nous continuons toutefois à rencontrer divers limiteurs de type 429. Le mode système sous forte charge ne s’est pas activé pour autant.
La saison de hockey a été gâchée par la COVID, et ils jouent maintenant quelques matchs au hasard sans public. Comme nous disposons de crédits d’hébergement chez UpCloud.com, nous faisons notre possible pour améliorer l’expérience avec ce que nous avons. Nous exécutons actuellement 6 cœurs virtuels avec 16 Go de RAM pour web_only et 4 cœurs virtuels avec 8 Go de RAM pour data, soit des licornes à 18.
Nous avons à nouveau désactivé le limiteur de débit…
DISCOURSE_MAX_REQS_PER_IP_MODE : none
…ce qui aide, mais nous recevons toujours des erreurs 429 lors des POLL, ce qui provoque de longs délais ou des freezes pour l’utilisateur final. Nous allons continuer à ajuster en augmentant DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
Mais avant de le faire, une question à @sam / l’équipe :
Existe-t-il une variable d’environnement pour augmenter le seuil du limiteur charge extrême - mode lecture seule, ou peut-il être complètement désactivé ?
Cela ne devrait pas être nécessaire. Nous serions ravis de vous héberger afin de comprendre pourquoi cela continue de se déclencher chez vous, même si votre trafic est si faible.
Peut-être, mais nous aimerions être un peu moins protecteurs envers le serveur, car les pics d’activité naturels sont très courts et se stabilisent généralement en une minute environ. Ainsi, ajuster légèrement les seuils à la hausse pourrait améliorer l’expérience utilisateur, en attendant le déplacement.
Les matchs ont été rares (grâce au COVID), nous avons donc eu très peu d’occasions de mesurer et d’expérimenter avec cela.
Nous avons découvert que, même avec nos ressources matérielles améliorées (6+4 cœurs vCores et 16+8 Go de RAM), une foule modérément active est capable de générer des erreurs 429 « client freezes ». Nous avons observé cela lors des matchs de la Coupe du Monde U20, qui ont attiré environ 50 % de notre audience habituelle pour les discussions.
Après avoir mesuré, testé et fait des essais et erreurs, nous avons opté pour les ajustements suivants :
Cela semble éliminer 80 % des erreurs 429, permettant ainsi une expérience relativement fluide pour la majorité des utilisateurs.
La prochaine étape aurait été d’acquérir différents types de ressources matérielles, soit en utilisant des serveurs dédiés pour la vitesse monothread, soit en passant à un fournisseur de VPS proposant des offres avec des milliers de vCores. Pour nous, cependant, la prochaine étape est de collaborer avec l’équipe d’hébergement Discourse, comme l’a suggéré @sam plus tôt.
Espérons que ces ajustements seront utiles à @iceman, @alec ou à toute autre personne. Veillez à surveiller l’utilisation du CPU et les files d’attente. De plus, ce que j’ai appris grâce à cet exercice, c’est que 2 conteneurs sont bien meilleurs qu’un seul : les ajustements peuvent être appliqués avec un temps d’arrêt quasi nul, et les ressources matérielles peuvent être exploitées de manière plus granulaire.
Je suis toujours intéressé par tout nouvel ajustement ou découverte qui pourrait aider à améliorer les performances et l’expérience utilisateur lors de discussions rapides animées par des événements réels.
