Merci. Vous m’avez probablement évité de nombreuses heures de débogage et d’essais-erreurs.
Cette différence de comportement m’a conduit à la conclusion qu’il s’agit d’une corrélation applicative découlant d’un problème côté FrontEnd « faisant planter » l’application (le FrontEnd n’étant pas mon domaine d’expertise, contrairement au BackEnd) et des opérations en cours liées à la publication et au fait que les utilisateurs restent sur un sujet en attendant qu’il se « mette à jour » tout seul avec des dizaines de messages en une seule minute.
Pour résumer cette phrase géante : votre conclusion est que l’« étouffement » dû aux discussions en temps réel rapides est un problème côté front-end ?
Je n’ai pas avancé loin dans notre analyse, mais j’ai observé que la charge du processeur était loin d’être maximale, seulement autour de ~25 %. Au fil des ans, nous avons déjà atteint 100 % de charge CPU à plusieurs reprises, mais ce n’était pas le cas lors du dernier incident samedi dernier. Nous n’avions que 150 utilisateurs simultanés environ.
Ce qui m’a poussé à suspecter le back-end, c’est le fait que nous exécutons ces chats de jeu depuis des années et que je n’ai jamais observé cet « étouffement » auparavant. Au fil des ans, la base de données a grossi et nous dépassons maintenant 800 000 publications.
Quand avez-vous remarqué ce problème pour la première fois ? Cela pourrait-il être une régression liée à la dernière mise à jour majeure ? Notre site et ses performances étaient corrects au printemps et nous n’avons pas connu une croissance significative durant l’été.
Babel est une extension spectaculairement inefficace. Si vous l’utilisez, vous allez passer un mauvais moment… surtout sous une charge importante d’utilisateurs actifs simultanément.
Nous avons désormais une tâche à faire dans notre backlog pour améliorer les performances dans les cas où 1 000 personnes consultent le même sujet et qu’une seule personne publie.
Conçu comme aujourd’hui, nous envoyons à toutes les 1 000 personnes un message du type : « Bonjour, il y a un nouveau message pour ce sujet », puis toutes les 1 000 personnes se tournent vers le serveur (principalement en même temps) pour demander : « Hé, quel est ce nouveau sujet dont vous parlez ? »
Nous allons examiner la possibilité de limiter le taux de requêtes de manière plus propre afin d’éviter que les clients ne surchargent le serveur, mais il existe de nombreuses optimisations que nous pouvons apporter pour ce cas atypique.
Excellente nouvelle que cela soit à l’ordre du jour. Pouvez-vous confirmer si cela a régressé depuis le printemps dernier ?
Notre ligue locale de hockey essaie de démarrer les matchs le 1er octobre. Cela signifie que notre site peut générer des pics de trafic hebdomadaires, au cas où vous auriez besoin ou souhaité étudier le comportement en temps réel, dans un environnement réel (non simulé).
Envoyez-nous un message privé si cela vous intéresse. Nous sommes heureux de soutenir.
Du point de vue de l’expérience utilisateur (UX), l’utilisateur final devrait en quelque sorte savoir que la discussion est active, même lorsque le système commence à ramer. Cela pourrait éviter des actualisations inutiles du navigateur.
Le premier match vient de se terminer et nous avons clairement un problème que nous n’avions pas en mars. La raison reste inconnue.
Le chat du jeu sature côté frontend, alors que la charge du serveur devrait être bien inférieure à 100 %.
Certains de nos utilisateurs ont relevé un certain nombre de réponses serveur 429 pendant ces saturations, mais je ne peux pas dire si c’est « normal », car nous n’avions jamais effectué une telle analyse pendant les matchs auparavant.
J’en ai vu un de ceux-là, alors que j’investiguais une erreur ‘500’ totalement sans rapport
Le serveur n’était absolument pas occupé, mais je manipulais une configuration front nginx (http2).
En effet. Il y avait environ 900 réponses réactionnelles en l’espace de quelques heures. @ljpp a des chiffres plus précis sur le nombre d’utilisateurs, mais nous parlons de centaines d’utilisateurs consultant le sujet à tout moment pendant le match.
Étrangement, cela n’affecte pas tous les utilisateurs. Moi, par exemple, je n’ai rencontré aucun problème sur aucun appareil. Mais selon les rapports, l’ampleur est suffisamment large.
Ce n’est pas si évident à repérer, surtout si vous ne faites pas très attention.
D’abord, il y a une pause de 30 à 60 secondes sans aucune réponse. Rien ne semble « anormal », c’est juste calme. Vous pouvez même écrire votre propre message. Puis soudainement, vous recevez des dizaines de messages en un instant et vous réalisez que vous avez pris du retard. J’ai observé cela sur iOS Safari et Android Chrome.
Nos discussions en temps réel pour les matchs sont animées, mais pas dans des cas extrêmes. Hier, nous avons eu 972 messages sur une période d’environ 3 heures.
Le prochain chat de match aura lieu aujourd’hui à 14h00 UTC. En raison de la pandémie, je m’attends à des chiffres similaires, même s’il s’agit d’un match à domicile.
Je suis d’accord avec le message de @pfaffman à ce sujet.
N’essayez-vous pas de forcer un cas d’usage de chat sur une plateforme de forum ?
Pourquoi ne pas intégrer plutôt un service de chat comme Mattermost ou Discord dans l’interface de votre site Discourse, et réserver ce média aux discussions en jeu ?
Vous pourriez trouver une autre façon de couvrir le jeu dans un sujet de forum, comme une discussion pré- ou post-match, où la charge d’utilisation pourrait être moins lourde, mais qui contiendrait peut-être des informations résumées utiles que de nombreux utilisateurs aimeraient consulter plus tard.
Je ne vois pas non plus l’intérêt de stocker un volume énorme de conversations spontanées sur un forum. Est-ce que quelqu’un va relire cela ? Est-ce utile ?
Eh bien, il utilise le mot « chat » pour cela, mais selon l’utilisateur, sa configuration Discourse ne peut pas gérer « 972 messages en l’espace d’environ 3 heures » dans un sujet. À mon avis, elle le devrait ; même un simple phpBB peut gérer plusieurs fois plus de messages en 3 heures que cela.
Donc 1 message toutes les 10 secondes ? Pris isolément, cela ne semble pas déraisonnable. Mais ensuite, vous faites en sorte que le sujet comporte 1000 messages, avec plusieurs centaines d’utilisateurs qui y participent, et en plus, vous avez des pics de publications. Je vois bien le défi !
Mais quel est le vrai coupable ou goulot d’étranglement ici ? Le nombre d’utilisateurs participants, un seul message toutes les 10 secondes, le rendu du contenu modifié pour (trop) d’utilisateurs anonymes ou non anonymes, ou le nombre de connexions nécessaires pour servir un grand nombre d’utilisateurs connectés ?
Rencontrera-t-il le même problème si seulement 2 utilisateurs produisent la même quantité de messages dans un sujet sur la même période ?
Même avec seulement 972 utilisateurs connectés ne faisant qu’un seul message dans ce sujet, Discourse ne serait-il pas capable de gérer cela ? Et si oui, pourquoi ? Discourse est-il simplement le bon choix pour de très petites communautés avec un faible nombre d’utilisateurs connectés simultanés ?
Je me demande simplement car nous avons déjà jusqu’à 400 utilisateurs connectés simultanés à certains moments, produisant jusqu’à 3000 messages par jour… jusqu’à présent, aucun problème.
Vous devez clairement prendre en compte les spécifications du serveur et le nombre de licornes en cours d’exécution, sinon les résultats de ces scénarios de stress perdent de leur pertinence.
Blenderartists (@bartv), je crois, dispose d’un serveur de 64 Go et d’une douzaine de licornes en cours d’exécution ? Vraiment une bête
Tout à fait, nous sommes actuellement sur 8 Go / 4 vCPUs chez DigitalOcean, sans aucun problème pour le moment. Donc, si la solution à ce problème consiste simplement à augmenter les ressources (RAM et CPU), cela me convient. Au pic depuis le redémarrage avec Discourse, nous avons eu environ 2000 visiteurs simultanés sur un seul post devenu viral, la charge était légèrement supérieure à 1 et le CPU à 60-70 %. En moyenne, avec environ 200-250 utilisateurs connectés simultanément, le CPU est à environ 15-20 % actuellement.
Vous pourriez avancer cet argument, mais je n’aime vraiment pas l’idée de fragmenter les conversations entre deux plateformes. La réactivité en temps réel est en réalité l’une des fonctionnalités phares de Discourse, que les utilisateurs finaux apprécient. Nos conversations pendant les sessions de jeu sont très appréciées et constituent une part importante de la culture de notre communauté.
Notez que nous les organisons depuis quatre ans et que c’est un nouveau problème auquel nous faisons face. Des centaines de sessions de jeu se sont donc déroulées sans incident, sans rien « imposer ».
L’un de nos membres a émis une théorie : pourrions-nous atteindre les limites globales de Discourse, et CloudFlare aurait-il un impact ?
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : nombre de requêtes par IP et par minute (la valeur par défaut est 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : nombre de requêtes par IP et par 10 secondes (la valeur par défaut est 50)
La prochaine session commence dans une heure ; nous testerons cela avec le cache de CF désactivé.
Notez que nous utilisons CloudFlare depuis 4 ans également, même si ce n’est généralement pas recommandé ici. Nous n’avons rencontré qu’un ou deux problèmes en cours de route, dont l’un concernait Brotli et l’autre un modèle non mis à jour.
Oui, je comprends votre inquiétude ici. Je ne voudrais pas perdre la trace de certaines idées intéressantes qui se perdraient dans le chat. C’est un dilemme délicat.
