Notre site Discourse compte plus de 10 000 utilisateurs et environ 700 utilisateurs actifs par jour, qui publient en moyenne 10 000 messages par jour. Notre communauté génère plus de 160 000 vues de page par jour, y compris les robots d’indexation et les utilisateurs anonymes. Presque tous nos utilisateurs se connectent via des appareils mobiles.
Nous avons exécuté notre communauté en mode autonome sur un VPS unique disposant de 16 cœurs CPU et de 24 Go de RAM, avec le fichier config/app.yml configuré avec les valeurs suivantes :
Avec cette configuration, certains utilisateurs signalent que le site se charge lentement pour eux, et parfois, lors de la soumission d’un message, l’écran devient blanc (l’en-tête reste toutefois affiché). De plus, pendant les heures de pointe, les performances du site ralentissent parfois.
Pourriez-vous nous indiquer si notre configuration est incorrecte ou si nous avons besoin de plus de ressources ?
Merci beaucoup
10 000 publications par jour est un chiffre assez élevé par rapport au nombre de visites de page. Je peux imaginer que vous atteignez certaines limites de ressources ici, étant donné votre configuration, et je soupçonne que cela concerne la base de données. Vous pourriez essayer de passer à une configuration multi-conteneurs, déchargeant ainsi les workers Unicorn du serveur principal.
Selon votre réponse, augmenter les ressources dans cette configuration ne permet pas de résoudre notre problème ? Par exemple, 24 cœurs de processeur avec 32 Go de RAM.
C’est tout à fait possible, mais je commencerais par mettre à l’échelle tout ce qui peut l’être horizontalement, et ce de manière horizontale. Cela vous donnera également une bien meilleure idée de l’endroit où se situe votre goulot d’étranglement.
La plupart des problèmes de performance peuvent être résolus en jetant simplement plus de ressources sur le problème. La partie difficile consiste à le faire de manière intelligente afin d’économiser de l’argent (ou potentiellement beaucoup d’argent).
Merci pour votre expertise et vos conseils amicaux. Je lirai certainement comment mettre cela en œuvre. Une autre question que j’ai est de savoir quels paramètres doivent être appliqués dans l’application pour les spécifications que j’ai mentionnées ci-dessus (24 cœurs de processeur avec 32 Go de RAM). Les paramètres actuels sont-ils appropriés ou vaut-il mieux augmenter les valeurs ?
Difficile à dire sans inspecter le système et voir ce qui se passe.
Puisque vous avez indiqué que la plupart des problèmes surviennent lors de la soumission d’un message, le problème vient probablement des écritures dans la base de données. Je ne pense pas que l’augmentation supplémentaire de shared buffers soit d’une grande aide, mais vous pouvez essayer. J’ai vu cette valeur portée à plus de 50 % de la mémoire (contre tous les conseils), vous pouvez donc essayer de l’augmenter progressivement jusqu’à 12 Go.
Si vous ne rencontrez pas d’erreurs 502, il n’y a aucun intérêt à augmenter UNICORN_WORKERS non plus.
Vous ne mentionnez pas son utilisation, c’est pourquoi je pense que la première chose à faire serait d’ajouter un CDN. Cela allégerait considérablement la charge du VPS, car les requêtes les plus volumineuses ne toucheraient pas le serveur.
En plus du CDN, je vous recommanderais également d’utiliser un stockage de type S3, ce qui vous permettrait de faire évoluer séparément le stockage et les ressources du VPS (si votre communauté génère beaucoup de téléversements).
Ces recommandations aident énormément à réduire la charge, et l’augmentation de prix est bien moindre que celle d’un VPS plus puissant.
Merci @marianord. Malheureusement, nous n’utilisons pas de CDN. Le taux de téléchargement sur notre forum n’est pas très élevé. La plupart du temps, les utilisateurs discutent de divers sujets. Par exemple, l’année dernière, nous avons eu environ 2,8 millions de messages et 2,7 millions de « j’aime », mais seuls 25 Go de fichiers ont été téléchargés.
Pensez-vous que, selon les informations que j’ai fournies, l’utilisation d’un CDN comme S3 réduirait la charge de notre serveur ?
Je ne suis pas d’accord avec @marianord. Je ne pense pas qu’un CDN ferait une différence notable en ce qui concerne la charge de votre serveur. Ce sont simplement des fichiers statiques et ils ne sont pas du tout lourds à servir.
S3 décharge les fichiers et les sauvegardes vers un autre serveur géré par un fournisseur de cloud (résumé très haut niveau)
Le CDN met en cache les fichiers statiques de votre serveur (images, JS, CSS) pour les servir depuis plusieurs serveurs (PoP) à travers le monde, afin d’accélérer le chargement de ces ressources.
Du moins, c’est mon expérience : vous réduisez le nombre de requêtes qui parviennent à votre serveur, ce qui diminue ainsi la charge. Il est beaucoup plus facile de servir seulement 10 requêtes JSON par utilisateur que 100 requêtes par utilisateur.
Cela ne résoudra peut-être pas tous les problèmes auxquels fait face @nildarar, mais cela réduira la charge lourde du serveur en retirant toutes les requêtes statiques (celles mises en cache) du serveur Discourse.
Une requête pour un fichier statique n’a pas un impact majeur sur la charge globale du serveur. Ce sont les requêtes pour le contenu dynamique qui sont les plus lourdes.
En général, une requête json n’est pas un actif statique qui sera mis en cache par un CDN. C’est du contenu dynamique généré à la volée. Pourquoi parlez-vous de fichiers JSON dans le contexte d’un CDN ?
Les requêtes statiques ne signifient pas une charge plus lourde.
Je suis désolé, mais ce sont vraiment de mauvais conseils.
Voici un exemple provenant d’une machine à 6 CPU (soit une capacité CPU totale de 600 %) exécutant Discourse sans CDN ni S3.
Vous pouvez voir que nginx n’est responsable que de 6,7 % (soit 1/100 de la capacité). Seule une partie de cela est utilisée pour les actifs statiques.
Si nous déchargeons les actifs statiques vers S3 et/ou un CDN, cela réduirait la charge globale du serveur de moins d’un pour cent.
C’est vrai, mais Discourse compte quelques exceptions, comme les feuilles de style servies par Ruby. Ainsi, l’utilisation d’un CDN en cache signifie que ces requêtes ne consomment pas de processus Unicorn.
Concernant le problème soulevé par l’auteur du sujet (OP), la première étape consiste à faire réaliser une analyse de performance par une personne compétente pendant les heures de pointe afin d’identifier le goulot d’étranglement actuel.
Merci pour vos conseils. Il y a quelques mois encore, nous utilisions le service CDN de Cloudflare et avons obtenu de bons résultats pour la mise en cache du contenu statique grâce aux règles de page. Par la suite, j’ai lu quelque part que l’utilisation de proxys comme Cloudflare réduisait considérablement les performances de Discourse, nous l’avons donc désactivé.
Hier, nous avons augmenté le nombre de cœurs CPU de 16 à 24 et apporté les modifications suivantes dans app.yml :
Grâce à ces modifications, notre problème a été résolu temporairement, mais je pense que nous devrions apporter un changement fondamental dans les prochains mois.
Donc, selon vos recommandations, l’utilisation d’un CDN pour servir le contenu statique et la séparation de Discourse en deux conteneurs distincts ont une priorité plus élevée en matière d’amélioration des performances.
Ces informations peuvent être obsolètes, mais je me souviens avoir lu que Discourse préfère un nombre plus faible de CPU plus puissants plutôt qu’un nombre plus élevé de CPU moins performants… même si vous mettez à jour le nombre de workers unicorn.
@codinghorror, pouvez-vous confirmer si ces informations sont toujours exactes ?
Notre prévision indique que le nombre de nos utilisateurs triplera l’année prochaine ; dès aujourd’hui, nous devons donc prévoir les ressources nécessaires pour cette échelle.
L’utilisation d’outils comme Prometheus + Grafana peut vous aider à consulter l’historique des données, plutôt que de les observer en temps réel, puis à effectuer une analyse plus approfondie de ce qui se passe.
Bonjour à nouveau
Suite à vos conseils, nous avons installé Prometheus et surveillé les performances de la communauté pendant un certain temps. Veuillez consulter les rapports ci-dessous et les comparer avec les valeurs que vous observez dans différentes installations.
