Nous venons d’enregistrer un pic de trafic d’environ 1 500 utilisateurs simultanés (principalement anonymes) visitant une seule page.
Le forum est alors passé en mode où un avertissement concernant la forte charge est affiché à tous les membres.
Droplet Digital Ocean optimisé pour le CPU
CPU dédié : 4 vCPUs
RAM : 8 Go
Processus Unicorn : 10
Étant donné que seuls environ 50 % de la RAM et du CPU sont utilisés, serait-il utile d’augmenter le nombre de processus Unicorn pour ce type de pics de trafic provenant de visiteurs anonymes, ou non ?
J’ai porté le nombre de workers à 24. Aucune différence (cela affiche toujours « En raison d’une charge extrême, cette page est temporairement affichée à tous comme le verrait un utilisateur déconnecté »), avec un pic de visiteurs simultanés similaire (99 % anonymes) à l’instant :
@sam Des idées pour optimiser davantage en cas de pic de trafic provenant d’utilisateurs anonymes (par exemple, si un sujet unique devient viral sur les réseaux sociaux) ? Dans les deux cas mentionnés ci-dessus, la mémoire et le CPU ont encore beaucoup de marge (selon Digital Ocean), et nous n’avons même pas atteint une charge de 4. Pourtant, le forum passe en mode « charge extrême », malgré le fait que le nombre de workers ait été triplé.
Je pense que le moniteur de données de DO n’est pas assez sensible et est quelque peu trompeur. J’ai expérimenté une charge extrême avec Hetzner et Digital Ocean. Avec Hetzner, lorsque le message de charge extrême est apparu, il y a eu un pic court et net où le CPU a atteint 120 %.
Cela a duré peut-être une seconde, avant de redescendre au niveau de 40-50 %.
J’ai reproduit la même chose avec Digital Ocean, et de mémoire, l’utilisation du CPU n’a jamais dépassé 50 % (mais vous ne pouviez pas ajuster l’axe des abscisses au niveau des secondes).
Mon hypothèse est que le niveau CPU de DO est peut-être la moyenne sur 5 ou 15 secondes. Ainsi, vous ne voyez pas les pics courts et nets.
Nous aurons besoin des rapports d’exportateur Prometheus pour approfondir l’analyse.
Si vous disposez de la RAM et du CPU nécessaires, vous pouvez toujours ajouter davantage de workers Unicorn, ce qui permettra de monter en charge lors des pics. Il suffit d’éviter le swapping de la mémoire, car les performances chuteraient considérablement.
Il semble que, dans un tel cas, la page de ce sujet unique devrait pouvoir être mise en cache et servie de manière statique pendant une courte période, sans avoir à toucher du tout au backend. Je ne sais pas si Discourse peut le faire (c’est-à-dire définir des en-têtes de contrôle du cache sous charge et servir du contenu aux utilisateurs anonymes) ni si la configuration DO dispose d’un proxy de cache capable dans la chaîne, mais c’est une idée de développement qui pourrait valoir la peine d’être envisagée si je ne me trompe pas totalement et que cela n’est pas déjà fait.
Peut-être que @sam y a déjà pensé ou l’a déjà fait, ou sait pourquoi ce serait une mauvaise idée !
Oui, mais je suggère de rediriger uniquement les utilisateurs anonymes vers une page mise en cache avec un court délai d’expiration (60 s ?) afin de réduire leur charge, dans l’espoir que le reste du site puisse continuer à fonctionner en mode lecture-écriture.
Ce serait formidable. Actuellement, si nous mettons en avant un sujet sur notre chaîne Telegram de plus de 200 000 abonnés, cela place l’ensemble du site Discourse en mode « lecture seule » pendant près d’une heure. Bien que le nombre d’utilisateurs connectés ne soit que d’environ 50 (99 % du trafic est anonyme).
Cela se produit déjà : nous mettons en œuvre une mise en cache très agressive directement dans Redis pour les utilisateurs anonymes sur les pages de liste de sujets et les pages de sujets, avec un délai d’expiration de 60 secondes.
Je vais essayer de lancer Prometheus pour identifier le goulot d’étranglement, mais il est probable que ce soit la surveillance de DigitalOcean qui soit en retard, comme l’a mentionné @Alec. Si c’est le cas, je suppose qu’une machine plus puissante est la solution à envisager ?
