J’ai essayé de chercher, mais je n’ai rien trouvé de récemment publié, alors j’ai pensé demander pour déterminer ce qui est normal et attendu.
Je viens d’autres forums, et le premier chargement de page est raisonnablement rapide, mais avec Discourse, la page se charge, mais je suis présenté avec un cercle qui tourne pendant qu’il attend que la page se rende - je ne suis pas sûr si c’est un délai du serveur ou un délai client / JS dans la construction de la page en fonction du résultat renvoyé par le serveur.
Le délai est d’environ 5 à 10 secondes - mais généralement les performances sont bonnes après cela.
Si le problème est susceptible d’être lié au serveur/hébergement, quel est le problème normal - car les métriques sur tout semblent basses. Le CPU, le disque et la mémoire ne semblent pas être saturés, donc je ne sais pas où investir $$ si le résultat n’est pas vraiment lié au serveur. Des conseils pour surveiller ou observer des métriques qui peuvent aider à montrer où Discourse passe son temps à attendre des choses ??
Dernière version 2.8.x et seulement une trentaine d’utilisateurs. Je fonctionne sur un vCPU dual core avec 2 Go de RAM et un disque SSD.
Comme mentionné, toutes les métriques sur le serveur n’indiquent aucune charge, donc je ne comprends pas pourquoi il y a 5 secondes de chargement avant que la page ne soit entièrement rendue.
Alors, n’y a-t-il rien à vérifier ou à surveiller, juste installer et espérer que tout va bien ??
En fait, c’est plutôt que le serveur se refroidit, et je demande simplement un rafraîchissement de page qui n’a pas été effectué depuis un moment - les parties backend se mettent-elles en veille ou autre, de sorte qu’une utilisation peu fréquente signifie que la première personne attendra probablement un peu plus longtemps que d’habitude ?
Quand vous dites 30 utilisateurs, parlez-vous d’utilisateurs simultanés ou de la base d’utilisateurs entière ?
S’il s’agit de 30 utilisateurs simultanés, votre configuration pourrait être un peu faible.
Quelle est la mémoire moyenne utilisée, 30-50-80% ???
Je regardais les graphiques de vitesse et de performance de G Analytics, j’ai remarqué un changement depuis que nous sommes passés de 2.2 à 2.9, une amélioration, mais je dois regarder de plus près. Je ne ressens pas vraiment de ralentissement notable, au contraire, cela semble plus rapide. Alors, que sais-je ou que sait G Analytics, hein !
J’ai également lu à propos de la limite de 10 000 messages par sujet, que si vous avez beaucoup de messages, il doit, je crois, charger l’intégralité en mémoire avant de l’afficher, et cela est perçu comme une lenteur au premier abord.
Je trouve qu’une fois qu’il a chargé quelque chose, tout devient rapide. Je ne suis pas un expert, mais cela pourrait aussi être le navigateur et toutes sortes d’autres astuces utilisées pour offrir l’expérience Discourse.
S’agit-il d’un VPS chez un hébergeur ou autre chose ? Comment a-t-il été installé ? Savoir quels sont les 2 processeurs est utile : tous les processeurs ne sont pas égaux.
Y a-t-il quelque chose entre l’instance et les clients ? Un proxy inverse ou quelque chose comme CloudFlare ?
J’ai enfin ouvert les outils de développement et je peux voir quelques messages d’erreur… il semble que a) les polices manquent ou ne sont pas trouvées et b) qu’il utilise l’adresse IP au lieu du FQDN correct - dont je ne suis pas sûr si l’adresse IP est correcte
The FetchEvent for "https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9" resulted in a network error response: the promise was rejected.
Promise.then (async)
(anonymous) @ Router.mjs:60
The FetchEvent for "https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9" resulted in a network error response: the promise was rejected.
Promise.then (async)
(anonymous) @ Router.mjs:60
NetworkFirst.mjs:167 Uncaught (in promise) no-response: no-response :: [{"url":"https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9"}]
at a.makeRequest (https://community.hubivue.com/javascripts/workbox/workbox-strategies.prod.js:1:2145)
makeRequest @ NetworkFirst.mjs:167
color_definitions_light_4_1_530ebcc4a553d42866a6f343d784841cf5c0b816.css:1 GET https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9 net::ERR_FAILED
NetworkFirst.mjs:167 Uncaught (in promise) no-response: no-response :: [{"url":"https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9"}]
at a.makeRequest (https://community.hubivue.com/javascripts/workbox/workbox-strategies.prod.js:1:2145)
makeRequest @ NetworkFirst.mjs:167
color_definitions_light_4_1_530ebcc4a553d42866a6f343d784841cf5c0b816.css:1 GET https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9 net::ERR_FAILED
Far out… J’ai réinitialisé les polices par défaut (c’est-à-dire Arial) et tout fonctionne bien. On dirait un bug ou quelque chose qui ne va pas avec la sélection des polices dans la configuration. Affaire classée et je vais me contenter d’Arial pour l’instant.
Cela dépend de la façon dont ils sont passés au nom d’hôte après avoir essayé d’utiliser l’adresse IP.
Cette installation a-t-elle été effectuée en suivant les étapes de l’installation standard ? Je parlerais à la personne qui a mis en place l’instance pour savoir ce qui a été fait. L’adresse IP peut toujours être référencée ailleurs.
Existe-t-il une commande pour réinitialiser l’installation ou corriger cela ? Il semble idiot que vous ne puissiez plus jamais changer le nom d’hôte. Est-ce une limitation intentionnelle ?
Notez que les performances sont bonnes maintenant que les polices de base sont utilisées - les problèmes semblent liés à l’utilisation des polices Google Roboto.
Ça ne peut pas faire de mal d’essayer, mais si vous ne connaissez pas l’historique de l’instance, nous ne pouvons même pas confirmer si vous exécutez une installation officiellement prise en charge.
