429 trop de requêtes

Salut à tous, je sais qu’il existe déjà des sujets sur les « too many requests », mais celui-ci ne semble pas tout à fait correspondre.

Je rencontre des erreurs 429 intermittentes sur Discourse (et tout est globalement assez lent) avec cette pile d’appels :

Error: Too Many Requests
    at s (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9188)
    at a (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9045)
    at o (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:8936)
    at Object.trigger (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:7223)
    at https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:9212
    at t.invoke (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:9729)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:8732)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:10782)
    at e.n._end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:15440)
    at e.n.end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:12110)

C’est toujours ce lien .js, un bloc de JS assez impressionnant qui ne signifie pas grand-chose pour moi. L’instance exécutant Discourse semble être sous une charge minimale — 10 % du CPU, tout le reste semble assez normal, donc il est un peu déroutant pour moi de recevoir des erreurs 429.

Y a-t-il des paramètres que je peux augmenter quelque part pour modifier la limitation de débit globale ? L’instance peut gérer beaucoup plus de charge que ce que Discourse semble penser, ou bien il manque quelque chose de plus important causé par un plugin ou un bug.

Merci !

Votre site est-il derrière un proxy inverse ou tout autre élément susceptible de fausser les adresses IP réelles entrantes ?

Non, je ne le pense pas (et les journaux capturent normalement les adresses IP), mais cela se trouve derrière un ELB. Cela a définitivement correspondu à une augmentation significative du trafic (cela ressemble un peu à une attaque DDoS ou quelque chose de similaire)

Mais si ma compréhension de la limitation de débit est correcte, cela n’aurait pas dû affecter tous les utilisateurs — seulement l’utilisateur essayant de visiter un million de fois, n’est-ce pas ?

Je vais vérifier concernant l’architecture réseau. Merci !

Je pense que le nginx à l’intérieur du conteneur Discourse utilise l’adresse IP du ELB pour le bucket de limitation de débit au lieu de l’adresse IP originale du client.

Cela semble tout à fait possible. Je viens de vérifier que nous avons bien une configuration ELB sur AWS, sans rien de particulièrement spécial. Est-ce le résultat d’une mauvaise configuration de ma part ?

Je ne suis pas tout à fait certain des prochaines étapes. Si vous pouvez m’orienter dans la bonne direction, je pourrai probablement travailler avec mon équipe ops pour résoudre le problème. Merci beaucoup !