Mes reconstructions prennent environ 10 minutes. Je pense qu’elles prenaient plutôt 5 minutes. Donc ce n’est pas grave. Que signifie le message d’erreur cependant ? J’obtiens quelque chose de similaire à celui du post original ci-dessus :
I, [2022-06-20T21:41:47.107238 #1] INFO -- : cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'
warning "eslint-config-discourse > eslint-plugin-lodash@7.1.0" has unmet peer dependency "lodash@>=4".
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
Je vais également ajouter des éléments à cela, j’utilise un système léger (1 Go de RAM) et un petit site. Il a 2 processus unicorn et chacun d’eux utilisait 30 % de la mémoire, ce qui provoquait beaucoup de memory thrashing, j’ai donc décidé de réduire le nombre de 2 à 1 (ce qui, je crois, peut gérer environ 10 connexions simultanées chacun). Cela a fait une ÉNORME différence, a rendu le chargement des pages presque instantané et a réduit le swapping d’un facteur de 5 à 10 (selon ce qui était chargé).
Le seul inconvénient que je vois maintenant est que je ne peux plus utiliser les mises à jour du navigateur pour mettre à jour Discourse. Lorsque j’essaie de mettre à jour via un navigateur, j’obtiens :
ABORTING, you do not have enough unicorn workers running
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: Not enough workers>
Donc, juste quelque chose à noter, je ne sais pas si c’est quelque chose que l’équipe Discourse peut résoudre/aborder - effectuer des mises à jour du navigateur avec un seul processus unicorn.
C’est faux. Une seule licorne ne peut gérer qu’une seule requête à la fois, donc bien qu’utilisable pour de petits groupes, ce n’est pas quelque chose que nous recommanderions pour la plupart des sites.
@Falco J’ai examiné les données d’autres administrateurs. D’après ce que je comprends, chaque Unicorn crée un nouveau processus pour chaque connexion entrante. Donc, bien qu’il s’agisse techniquement d’une connexion à la fois, chaque unicorn peut gérer plusieurs utilisateurs simultanés.
D’après l’expérience partagée ci-dessous, environ 8 Unicorns peuvent gérer environ 400 utilisateurs simultanés.
Sur cette base, il semble que chaque unicorn puisse gérer environ 50 utilisateurs simultanés. Je sais maintenant que la RAM et les ressources système font une différence dans le nombre de forks qui peuvent être effectués, etc., d’où mon hypothèse qu’un worker unicorn peut gérer 10 utilisateurs simultanés sur un système avec peu de RAM (1 Go) au plus bas.
Mes hypothèses et conclusions sont-elles complètement erronées ? Si oui, quelle serait la plage d’utilisateurs simultanés que chaque unicorn peut gérer en fonction des ressources système (en supposant 1 Go au plus bas et tout ce que vous jugerez approprié au plus haut) ?
Il y a une différence entre les sessions utilisateur simultanées et les connexions simultanées. Une session est un utilisateur en ligne, et chacun d’eux fait une requête (connexion) chaque fois qu’il interagit.
Il ne le fait pas. Unicorn se divise en un nombre défini de processus de travail au démarrage.