J’ai une nouvelle installation d’Ubuntu 20, Docker et Discourse. Je n’ai ajouté aucun plugin et j’ai seulement deux utilisateurs dans ma base de données, cependant les builds prennent plus de 40 minutes à se terminer ! Il n’y a pas de partie spécifique du processus de build qui soit lente, l’ensemble prend une éternité à se terminer. C’est un serveur avec de bonnes spécifications, et j’en ai un autre qui dessert avec succès 20 sites web de mes clients, donc ce n’est pas un problème de performance.
Se bloque ici pendant au moins 4 minutes :
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
Se bloque à nouveau ici immédiatement après pendant encore 4-5 minutes :
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
J’ai essayé de construire avec --skip-prereqs sans succès, cela prend toujours 40+ minutes à chaque reconstruction.
Y a-t-il quelque chose en particulier qui pourrait causer le problème ?
Nous avons une régression sur les temps de build causée par la nouvelle capacité d’exécuter des tests de thème via l’interface utilisateur. C’est quelque chose que nous suivons de près et que nous essayons de corriger.
Merci de confirmer @Falco, 1 Go de RAM ici (juste assez mais jamais eu besoin de plus pour un site léger). La construction prend plus de 30 minutes (normalement environ 10).
Rafael, s’agit-il d’une régression sur la version bêta 2.9.0 ou la version stable 2.8.0 ?
Pour en revenir au premier message, quelqu’un sait d’où vient cet avertissement ?
Je ne sais pas si c’est vraiment quelque chose à considérer, mais personnellement, dans beaucoup de choses j’ai remarqué que les performances chutent lors de l’utilisation d’Ubuntu 20.04 (Discourse, WebServers, Game Servers) même en essayant différentes façons d’essayer d’optimiser
Au moment où j’écris ces lignes, je fais tourner Discourse dans un Droplet pour des tests avec les mêmes caractéristiques, il faut environ 8 à 12 minutes pour reconstruire (Ubuntu 18)
Je ne pense pas que la compilation soit « bloquée » à ces avertissements. Elle compile simplement silencieusement et les avertissements sont émis dans le cadre du processus.
Autrement dit, les avertissements ou leur problème sous-jacent ne contribuent pas au long temps de compilation.
C’est un changement gigantesque sur lequel nous travaillons depuis des années et qui arrive à ses dernières étapes. Pendant ce temps, nous avons une période où « les choses vont empirer avant de s’améliorer », et c’est l’un des effets secondaires « pires » de cela.
Il y a aussi la possibilité pour nous de permettre aux personnes ayant des CPU lents de désactiver les source maps et autres fonctionnalités « agréables à avoir » pour accélérer leurs reconstructions.
Merci pour la mise à jour @Falco Sur un CPU quad avec 8 Go de RAM sur Linode et normalement c’est une configuration fantastique, mais c’est un cauchemar maintenant. Nous avons un certain nombre de changements que nous avions prévu de faire, mais nous devrons attendre maintenant jusqu’à ce que le déploiement revienne à des vitesses normales.
@Falco Je remarque également que depuis quelques versions, les performances du serveur se dégradent, il faut plus de temps pour charger les sites et consommer plus de mémoire. Il n’y a eu aucun changement dans ma configuration au cours des 2 dernières années (plugins, matériel, etc.) et le nombre d’utilisateurs actifs sur le site est également le même. Existe-t-il un moyen de surveiller objectivement les performances du site depuis Discourse que nous pourrions ensuite signaler ici. Pour l’instant, la seule façon que je connaisse est lorsque j’ouvre le site, il faut plus de 8 secondes pour le charger la première fois (avec les versions précédentes, cela prenait toujours moins de 2 à 3 secondes).
Quels sont les temps de reconstruction que vous observez ? J’ai juste eu besoin de reconstruire suite à un changement SMTP, et cela a pris un peu moins de 12 minutes pour un site minuscule (30 utilisateurs, 400 publications).
Ce sujet porte sur les « temps de build » et non sur les temps de chargement des pages. Si vous parlez de la dégradation des temps de réponse des pages, veuillez ouvrir un nouveau sujet à ce sujet avec des données.
Je pense avoir trouvé pourquoi le chargement des pages prenait autant de temps. La taille de la base de données partagée dans app.yml était définie sur la mémoire totale du système. Je l’ai réinitialisée à la valeur par défaut (25%), reconstruite et maintenant c’est moins d’une seconde.
Merci pour la mise à jour 
Sur un CPU quad avec 8 Go de RAM sur Linode et normalement c’est une configuration fantastique, mais c’est un cauchemar maintenant. Nous avons un certain nombre de changements que nous avions prévu de faire, mais nous devrons attendre maintenant jusqu’à ce que le déploiement revienne à des vitesses normales.