Nous avons 5 millions de publications et la recherche est très réactive. L’hébergement s’effectue sur 6 cœurs partagés d’un Xeon E5-2680 à 2,8 GHz, avec 16 Go de RAM et un stockage SSD. Cela dit, je ne dispose pas de métriques sur le nombre de publications simultanées lancées par nos utilisateurs ; il pourrait y avoir des problèmes de verrouillage.
La publication, en revanche, est souvent assez lente. Il peut falloir 6 à 7 secondes pour qu’une publication soit prise en compte. Discourse fonctionne de manière non bloquante lorsqu’il est en pleine activité, ce qui ne nuit donc pas à l’expérience utilisateur.
Je pense que c’est très probablement le cas pour n’importe quel sujet comptant des centaines ou des milliers de messages. Sur des sujets courts, cela ne devrait pas être le cas.
Je me souviens que le forum de @Wingtip regorge de sujets très longs.
Les délais de publication de 6 à 7 secondes sont-ils spécifiques aux sujets géants ? Si vous répondez à un sujet comportant 100 réponses, cela prend-il également 6 à 7 secondes ?
Je n’ai pas pu reproduire le problème à l’instant — la lenteur des publications est intermittente. Elle ne semble pas corrélée au nombre de messages dans le fil. Peut-être s’agit-il d’un problème de verrouillage lié à une publication simultanée d’un autre utilisateur ou quelque chose de similaire.
7 messages = très rapide, à peu près comme ici sur meta
500 messages = peut-être légèrement plus lent, pas trop grave. Peut-être 1,5 seconde ?
16k messages = semble à peu près identique à 500
Et je pense que les performances sont également affectées si un grand nombre de personnes accèdent à un sujet majeur, ce qui ralentit l’ensemble du serveur PG en raison des requêtes mises en file d’attente.
Cela a du sens de privilégier l’expérience de nombreux utilisateurs qui consultent un fil de discussion plutôt que celle d’un ou deux qui tentent de publier.
Comment vous sentez-vous courageux ? Ne seriez-vous pas d’accord pour activer mini_profiler pendant un moment ? Cela vous affichera les temps d’exécution sur le côté, ce qui nous permettra d’isoler la requête qui pose problème pour vous !
Dans quelle mesure son activation impacte-t-elle les performances globales ? Et peut-elle être activée sans reconstruire le site ? Je n’ai pas réussi à effectuer une reconstruction depuis le changement vers PostgreSQL 12, même en forçant le maintien sur PG10.
Vous devez définir votre adresse e-mail comme adresse e-mail du développeur dans le fichier app.yml. Vous pouvez l’appliquer sans reconstruire en détruisant et en redémarrant le conteneur. Si vous avez apporté des modifications au conteneur en le mettant à jour avec Discourse Docker, elles seront perdues.
Vous pouvez également modifier config/discourse.conf à l’intérieur du conteneur, puis exécuter :
Étant donné que les reconstructions échouent, je crains que si je détruis le conteneur, je serai complètement à court d’options. J’ai rencontré tellement d’erreurs en tentant la mise à niveau vers PostgreSQL 12 hier que je ne me sens vraiment pas à l’aise de procéder à des modifications tant que je n’aurai pas l’assurance de ne pas mettre le site hors service pendant une période prolongée.
Eh bien, les conseils gratuits valent ce qu’on en paie, mais il est assez sûr de faire :
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# dans vi, éditez la ligne developer_emails pour y mettre votre adresse e-mail, puis quittez vi
sv unicorn restart
# paniquez pendant les 30 à 90 secondes nécessaires au serveur web pour redémarrer et commencer à servir les pages
Cependant, vous pouvez toujours casser des choses de cette façon. Je pense qu’il est possible de salir ce fichier de configuration au point que Discourse ne démarre pas.
Est-ce ce dont vous aviez besoin ? Cela a été publié dans un fil de discussion comportant 16 000 messages. Cela semblait être un temps de publication normal, pas particulièrement lent.
Super ! Toute amélioration substantielle du temps de publication rendra vraiment nos utilisateurs heureux ; c’est actuellement le sujet le plus critiqué. Bien que je ne doute pas qu’ils trouveront rapidement autre chose pour se plaindre.
Si cela peut te rassurer, je me suis aussi plaint de cette requête, car j’ai un état de lecture très chargé ici sur Meta. Nous effectuons un travail inutile pour compter des choses à chaque réponse…
Lors de notre test d’importation depuis un autre logiciel, nous avions un sujet avec un peu plus de 200 000 messages, et j’ai pu y poster sans problème. Cela doit être dû au fait que ce n’est pas la taille du sujet qui compte, mais plutôt l’utilisateur qui effectue la publication.
