Il existe des commandes comme rake posts:rebake (par exemple, après une migration).
Y a-t-il d’autres commandes ou autre chose qui pourrait accélérer le forum ? J’ai l’impression que, après avoir changé d’hébergement avec plus de RAM, c’est probablement encore plus lent. L’ajout de Go n’a pas aidé, même si je teste sans aucun trafic. Je me demande s’il existe des commandes pour optimiser la base de données, etc., car peut-être est-ce la raison pour laquelle la navigation entre les liens est terriblement longue et lente (1 à 2 secondes). C’est un peu décevante par rapport à NodeBB, par exemple.
Si vous modifiez la RAM de votre serveur, vous devez exécuter à nouveau discourse-setup pour ajuster les paramètres de mémoire.
Quelle est la taille de votre base de données ? S’agit-il d’une importation ou d’une nouvelle communauté ? Quelle est la vitesse du processeur ? La vitesse d’un seul cœur CPU est cruciale. Vous avez bien un SSD et non des disques mécaniques, n’est-ce pas ?
Lightsail est vraiment conçu pour les applications web et les sites web simples.
Vous disposez d’un seul cœur de processeur, ce qui signifie 2 processus unicorn, mais votre paramètre shared_buffers pourrait être augmenté à 512 Mo. Votre fichier app.yml devrait inclure ce commentaire :
Avec 2 Go, nous recommandons 3 à 4 processus, avec 1 Go seulement 2
Vous utilisez donc deux fois plus de processus avec la moitié de la taille de buffer recommandée.
Les disques mécaniques sont ce qui a précédé les SSD, bien que vous les connaissiez peut-être aussi sous le nom de disques durs ou HDD. Ils sont trop lents pour Discourse.
Ces paramètres sont généralement définis automatiquement par discourse-setup en fonction des spécifications du système (nombre de cœurs CPU, quantité de RAM) au moment où le script est exécuté. Il est également sans danger de l’exécuter à nouveau si les spécifications de votre serveur changent.
Il existe de nombreuses différences entre les types d’instances AWS. Certaines utilisent des disques basés sur EBS, qui passent par le réseau pour l’accès aux données, ce qui augmente la latence. D’autres disposent de disques NVMe locaux rapides, mais ils ne conservent pas les données de manière persistante. Il existe également les familles d’instances Z et C, offrant des performances de données bien supérieures.
Cependant, tout cela finit par être plus complexe et coûteux qu’une instance Droplet chez Digital Ocean, qui offre des performances acceptables pour les petites communautés à 5 et propose un processeur plutôt rapide dans son offre optimisée pour le CPU à 40 .
Quel offre exactement entendez-vous par « optimisée » ?
Par ailleurs, ma question s’applique également aux commandes elles-mêmes. Autrement dit, quelles commandes (comme « rake rebake posts ») dois-je exécuter pour optimiser / reconstruire les articles / supprimer les fichiers inutiles, etc. ?
Pourquoi y aurait-il une commande secrète pour accélérer les choses ? Pourquoi diable partir par défaut d’un mode lent ?
Si vous rencontrez des problèmes de performance, vous devez fournir des données concrètes. Quelle est la procédure lente, quelle est la taille de la communauté, quelle est la taille de la base de données, avez-vous essayé de supprimer tous les plugins et thèmes, avez-vous essayé de l’exécuter sur un droplet DO à 5 $, etc. ?
Je n’ai aucune intention de blâmer qui que ce soit, surtout que je n’ai pas examiné cela moi-même, en particulier l’instance/config PostgreSQL… mais Discourse est terriblement lent. Je ne sais pas ce qui en est responsable, je suppose que l’ORM Ruby y joue un rôle.
Bien sûr, vous pouvez toujours ajouter du matériel plus puissant, plus de SSD, plus de RAM… jusqu’à un certain point, mais cela ne change pas l’essentiel : Discourse est assez exigeant/lent, même pour des installations minuscules, il nécessite un hébergement décent.
Je suis en désaccord total avec cette affirmation. Je connais plusieurs petites communautés qui fonctionnent sur un VPS à 5 $. Une installation Discourse lente indique généralement un mauvais choix d’hébergeur ou une mauvaise configuration.
N’oubliez pas que Discourse n’est pas un site web, mais une application. Une fois chargée dans votre navigateur, les échanges de données sont minimes.
Si vous suivez le guide d’installation standard, qui est le seul que nous prenions en charge ici, tout le réglage du CPU/RAM est effectué automagiquement. Vous ne nous avez fourni aucun exemple ni comparateur ici ; je vous encourage vivement à nous donner des précisions.
Je peux bien sûr réaliser quelques benchmarks. Je l’exécute sur une machine virtuelle à 5 $, avec un matériel vraiment minimaliste selon les standards actuels, je le sais. Et je ne le comparais pas à d’autres solutions de forum, mais je sais ce que PostgreSQL peut gérer et fournir, même lorsqu’il est exécuté dans un conteneur Docker sur une machine virtuelle. J’ai presque 20 ans d’expérience dans le développement de bases de données.
D’accord, d’accord, et j’ai été un peu piqué par l’attitude du genre : « Est-ce que vous l’exécutez sur du matériel du siècle dernier, c’est-à-dire des disques mécaniques ? »
Je reformule en disant : « Discourse est plus exigeant que des systèmes plus simples. »
Pouvez-vous expliquer ce que signifie le terme « mauvaise configuration » ? Cela désigne les erreurs possibles lors de l’installation d’un forum vierge et de l’ajout d’au maximum 1 à 2 plugins. De quelle configuration parlez-vous ?
Que considérez-vous comme des performances adéquates ?
Décrivez les scénarios dans lesquels les performances ralentissent.
Comment avez-vous déterminé que la plateforme Discourse (ou même votre hébergement) est à l’origine de ce ralentissement ? Que la base de données est un facteur limitant, etc.
Peut-être pourriez-vous partager quelques liens webpagetest.org comme point de départ.
Bien que cela soit techniquement juste, je pense que cela manque le point de vue de la croissance communautaire et de l’expérience utilisateur. Il y a beaucoup à dire concernant le trafic que nos communautés attirent via les moteurs de recherche.
À mon avis, il est important que leur première visite sur ce lien se charge rapidement.
Et c’est le cas : à l’exception des communautés riches en ressources comme NPN, je ne vois pratiquement aucune communauté Discourse dont le temps de chargement final dépasse deux secondes, et le DOMContentLoaded se situe généralement bien en dessous de 1000 ms.
WebPageTest est une métrique peu fiable. Ouvrez un navigateur, inspectez le code source de la page, passez à l’onglet Réseau, videz le cache et forcez un rechargement complet. Toutes les données sont sous vos yeux.
Vous avancez qu’il y a un problème, mais vous ne nous donnez aucun exemple. Il serait vraiment utile si vous pouviez étayer ces affirmations.
C’est un outil parfaitement valable, qui peut servir de point de départ ou pour explorer plus en profondeur des scénarios spécifiques (système d’exploitation, localisation, bande passante, latence) si vous le souhaitez. C’est aussi un moyen pratique de partager les résultats d’un scénario contrôlé pour que d’autres puissent les examiner.
L’onglet Réseau est tout aussi valable, à condition de comprendre que vous voyez littéralement uniquement votre propre expérience, probablement depuis votre bureau et via la connexion que vous utilisez. C’est un bon test indicatif, cela ne prend que quelques secondes, et cela peut ou non vous donner les informations nécessaires pour optimiser l’expérience de vos visiteurs.
Les deux approches ont du mérite. Aucune n’est une « métrique terrible ».
@eextra, il est également utile de rappeler que vous devriez avoir un compteur de temps de réponse visible lorsque vous êtes connecté à Discourse en tant qu’administrateur. Vous avez également la possibilité de générer des rapports de performance NGINX via le panneau d’administration.
Quel est le problème avec les sites de test de vitesse des sites web ?
Je voulais ajouter mon grain de sable car je les utilise beaucoup et je les trouve utiles. Surtout ceux qui effectuent des tests depuis plusieurs emplacements et plusieurs fois lors d’une même session.
Je trouve intéressant que j’obtienne des résultats différents entre ces sites et mon navigateur lorsqu’il s’agit d’optimisations impliquant 100 à 200 ms, bien qu’ils semblent précis pour des durées supérieures.
Parfois, je choisis des optimisations qui satisfont les sites de test de vitesse des sites web, car s’ils rapportent tous des mesures similaires, je suppose que Google fait de même, ce qui pourrait être faux, car son algorithme est secret.
Ruby est un langage notoirement lent, Discourse utilise une quantité énorme de JavaScript, et il n’est guère contesté que le temps de chargement initial d’un forum Discourse soit long et que la vitesse sur mobile soit médiocre. Je pense que dire aux gens qu’ils obtiendront d’excellents résultats de vitesse avec le bon matériel n’est pas vraiment précis, car je navigue actuellement sur Meta et c’est en effet lent par rapport à, disons… un forum programmé en Go lol. J’utilise Discourse car il fonctionne bien, offre une excellente protection anti-spam, de grandes fonctionnalités et nécessite peu de maintenance. Je ne l’ai jamais considéré comme rapide, ni la plupart des visiteurs de forum qui ne le voient pas comme une « application » lorsqu’ils cliquent sur le premier lien Google pour visiter le site.
.
