Erreur de chargement extrême

« En raison d’une charge extrême, ceci est temporairement affiché pour tous, tel qu’un utilisateur non connecté le verrait »

Je gère un site web qui propose des fils de discussion en direct pendant les matchs de basket-ball et j’ai rencontré des problèmes de surcharge du serveur, ce message apparaissant lors des matchs (pics d’activité).

Existe-t-il un moyen d’identifier la meilleure façon de résoudre ce problème ? S’agit-il de la vitesse de stockage, de la mémoire, du processeur ? Y a-t-il quelque chose que je puisse faire autre que renforcer mon serveur, ou si je le fais pendant ces périodes… que devrais-je renforcer ?

2 « J'aime »

Que moins de personnes utilisent le forum ? Encore mieux serait de les inciter à étaler leur utilisation plutôt que de tous le faire pendant le jeu.

Mais rien de tout cela n’est vraiment utile. Puisque vous savez quand les jeux ont lieu, vous pourriez renforcer votre serveur uniquement pendant le jeu, ou faire fonctionner plusieurs serveurs pendant le jeu derrière un équilibreur de charge.

Vous avez besoin de cœurs CPU plus nombreux et plus rapides, ainsi que de plus de RAM, afin d’augmenter le nombre de processus Web (Unicorn Workers) pour gérer les pics de trafic.

4 « J'aime »

C’est un domaine sur lequel @sam travaille activement. Il semble que les versions plus récentes de Discourse aient régressé sur ce point, en termes de performance.

Cela dit, la véritable solution est d’utiliser un outil de chat en direct si vous avez besoin d’interactions en temps réel pour des centaines de personnes simultanément — bien que je continue de me demander comment et pourquoi le chat est « utile » lorsqu’il défile si vite que personne ne peut vraiment rien voir, comme sur les flux Twitch et YouTube. :man_shrugging:

2 « J'aime »

Ce fil de discussion décrit très bien le problème.

Voici mon expérience avec un forum de football en match avant que les problèmes ne surviennent :

Digital Ocean
1 CPU 1 Go = 30 à 40 utilisateurs dans une situation de type chat
2 CPU et 2 Go = 70 à 80 utilisateurs dans une situation de type chat
4 CPU et 8 Go = suffisant pour 120 utilisateurs et 1000 publications en 2 heures. La limite n’a pas été atteinte.

Avec Hetzner (site miroir)

Mon expérience :
3 CPU (puce AMD CPX 21) et 4 Go = difficultés avec 20 utilisateurs
2 CPU (Intel) et 8 Go = aucun problème avec 20 utilisateurs.

Je n’ai jamais eu l’occasion de tester avec plus d’utilisateurs.

L’essentiel est d’améliorer le CPU et la RAM. ET AUSSI de modifier le fichier app.yml.

Ajoutez plus de unicorns ici, et modifiez également db_shared_buffers.

5 « J'aime »

Pour les forums sportifs, cela se rapproche davantage des mises à jour textuelles en direct pendant les matchs. Les gens ne discutent pas tant que ça (bien que cela se produise dans une certaine mesure, surtout à la mi-temps) ; ils obtiennent plutôt un commentaire textuel en direct de la part d’autres supporters.

Beaucoup de gens se connectent au forum simplement pour lire ce commentaire en direct, découvrant les réflexions et opinions de personnes clés sur les événements majeurs du match. Cela va de réactions humoristiques à des analyses sérieuses.

Si vous avez manqué le match, les gens se connectent simplement pour lire le commentaire événement par événement. C’est idéal pour les gens au travail ;). C’est plus personnel et subjectif que le commentaire textuel des journaux ou des chaînes de télévision.

6 « J'aime »

C’est exact. discourse-setup fera cela si vous l’exécutez sur le serveur mis à niveau.

2 « J'aime »

Je vous comprends, c’est quelque chose que @sam, @eviltrout et moi examinons de près… la situation de « centaines d’utilisateurs connectés et naviguant sur le même sujet en même temps » se présente assez fréquemment récemment à mesure que Discourse gagne en popularité.

Nous pourrions avoir besoin d’inviter à un nouveau mode de comportement dans ces cas-là ; des panneaux de « voie rapide » devraient probablement commencer à apparaître dans l’interface des sujets sous une forme ou une autre… :warning:

4 « J'aime »

Il est important de garder à l’esprit que les implémentations de « chat » diffusent généralement le contenu réel aux abonnés.

Dans Discourse, nous avons un pipeline assez complexe qui rend l’implémentation naïve complexe et entraîne un trafic important.

  1. Un utilisateur publie une réponse
  2. Tous les utilisateurs consultent le sujet et découvrent via la diffusion qu’il y a du nouveau contenu
  3. Tous les utilisateurs demandent le contenu du post au serveur (100 spectateurs = 100 requêtes)
  4. Nous récupérons les images / optimisons les images
  5. Tous les utilisateurs consultent le sujet et découvrent via la diffusion qu’il y a du nouveau contenu
  6. Tous les utilisateurs demandent le contenu du post au serveur (100 spectateurs = 100 requêtes)

(nous avons diverses optimisations, limites de débit, nouvelles tentatives, etc., mais c’est l’essentiel)

Toutes ces requêtes doivent passer par notre pipeline de sécurité pour s’assurer que l’utilisateur a le droit de voir le post, etc.

Si le contenu était assez court et que nous pouvions trouver un moyen de mettre en œuvre la sécurité de manière plus légère pour la « voie rapide », nous pourrions distribuer les messages de chat via la diffusion. Cela entraînerait des performances nettement meilleures ; avec cette conception, nous pourrions probablement gérer 10 000 utilisateurs sur un seul petit droplet Digital Ocean de 2 Go.

La sécurité est très complexe. La mise en cache l’est aussi en raison des problèmes d’invalidation du cache.

Donc, oui, nous réfléchons absolument à ce problème. Mais pour l’instant…

Beaucoup de spectateurs connectés sur un sujet + beaucoup de nouveau contenu sur un sujet = des factures de serveur élevées.

7 « J'aime »

C’est fantastique !

Pour être honnête, je n’ai que juste assez de connaissances pour être dangereux. Je suis du genre à apprendre en jouant (et en cassant des choses). J’apprécie vraiment l’effort formidable déployé pour créer cette plateforme. Lorsque j’ai créé mon premier forum il y a 12 mois, j’en ai créé 12 versions différentes :laughing: Vanilla, MyBB, SMF, Flarum, etc. Discourse était de loin le meilleur.

L’un des plus grands atouts est le développement actif. C’est formidable de voir à quel point vous écoutez la communauté et l’améliorez continuellement.

6 « J'aime »

Avez-vous des paramètres recommandés pour cela ?

1 « J'aime »

Salut les gars, mon site semble avoir régressé, avec le même package DO (8 Go, 4 CPU), mon site commence à avoir du mal avec 60-70 utilisateurs postant 1000 messages.

Je me pose juste deux questions.

  • Est-il possible de supprimer le message de charge extrême ? Il semble alarmer les utilisateurs plus qu’être utile.

  • Des progrès dans la gestion d’un grand nombre d’utilisateurs ?

En attendant, je vais explorer la modification des unicorns, et la désactivation des plugins, etc. pour aider à libérer des ressources.

Si vous avez redimensionné après l’installation, avez-vous exécuté à nouveau discourse-setup ou modifié les paramètres manuellement ?

Je viens de le faire manuellement, aurais-je dû exécuter discourse setup ?

Si vous avez effectué les modifications, vous devez reconstruire (je ne suis pas sûr qu’un destroy/start suffise).

1 « J'aime »

Je m’assure juste de ne pas mal comprendre, après avoir modifié le fichier yml, j’ai simplement exécuté ./launcher rebuild app

Est-ce que ça vaut le coup d’essayer ./discourse-setup à la place ?

(Comme mentionné précédemment, j’ai juste assez de connaissances pour être dangereux :sweat_smile:)

Devrait aller. Discourse-setup modifiera les paramètres de mémoire pour vous. Si vous l’avez fait, vous devriez être tranquille.

1 « J'aime »

Juste pour être sûr et par curiosité : avez-vous configuré le swap ?

J’ai un fichier d’échange de 2 Go, recommanderiez-vous un fichier d’échange de 8 Go ? (correspondre à la quantité de RAM ?)

Si vous avez de l’espace disque, plus de swap ne fera pas de mal. free vous indiquera comment la mémoire est utilisée et quelle quantité de swap est utilisée.

1 « J'aime »