Problèmes lorsque j'active le composant, peut-être les blocs de la barre latérale droite ?

Je rencontre des erreurs, en avez-vous déjà vu et connaissez-vous une solution ? Je pensais que c’était un problème de mémoire sous Windows, mais cela se produit toujours même si j’ai 6 Go de libre sous Windows.

En revenant d’un sujet

En allant sur un sujet :

Ces erreurs sont intermittentes, mais se produisent assez souvent :frowning:

Merci pour toute aide. À noter que si je réessaie, cela réussit généralement… De plus, il n’y a rien à ce sujet dans /logs

Notez que j’ai également ajouté des blocs de tuiles en vedette, mais si je désactive les blocs de la barre latérale droite, le problème disparaît. J’ai 11 Go de mémoire libre et beaucoup d’espace disque.

Si je désactive les tuiles en vedette et que j’active les blocs de la barre latérale droite, le problème persiste.

1 « J'aime »

J’ai la même erreur que vous mais je ne sais pas comment la corriger même si je l’ai postée ici :joy: :joy: :joy:

Espérons que quelqu’un ait une idée :cry:

Je chercherais les erreurs dans la console du navigateur.

J’ai reçu 1100 lignes, voici une partie :

2 deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/top-contributors’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations

post.js:561 :white_check_mark: Utilisation du nouveau menu de publication ‘glimmer’ !
2deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/top-contributors’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Trop de requêtes)

:information_source: Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/whos-online’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations pour plus de détails.

C’est peut-être la cause. Dans ce cas, vous êtes probablement limité par le débit.
Vous pourriez vérifier l’onglet réseau de la console du développeur, s’il y a plus de requêtes lorsque les blocs de la barre latérale droite sont activés.

1 « J'aime »

Une question si quelqu’un sait :

(1) Je suis un administrateur, niveau de confiance 4, alors pourquoi « DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL » ne me permet-il pas de contourner les limitations de débit ?

Limitations de débit globales par adresse IP
Ces limites s’appliquent à chaque adresse IP unique qui accède à l’application Discourse. (les fichiers servis directement depuis le système de fichiers ou le CDN sont exclus)

Par défaut, cette limitation de débit est activée, vous pouvez la désactiver ou la définir en mode de rapport.

DISCOURSE_MAX_REQS_PER_IP_MODE : blocage par défaut, cette limitation de débit s’applique dès l’installation. (d’autres options sont avertir, avertir+bloquer et aucune)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : nombre de requêtes par IP par minute (la valeur par défaut est 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : nombre de requêtes par IP par 10 secondes (la valeur par défaut est 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS : nombre de requêtes d’assets (avatars/css) par IP par 10 secondes (la valeur par défaut est 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE : la limitation de débit doit-elle s’appliquer aux adresses IP privées accédant à Discourse ? la valeur par défaut est false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL : utiliser les limitations de débit par utilisateur plutôt que par IP pour les utilisateurs ayant ce niveau de confiance ou plus (la valeur par défaut est 1)

Pour modifier les limites, ajoutez la modification souhaitée dans votre fichier app.yml dans la section env.

Je pourrais essayer :

DISCOURSE_MAX_REQS_PER_IP_MODE: warn
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 600
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 200
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 400
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: false
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: 2

J’ai également vérifié le journal d’accès nginx, il affiche des adresses IP différentes pour nos utilisateurs. (J’ai vu dans un sujet beaucoup plus ancien où c’était un problème, tout le monde utilisait la même adresse IP pour l’accès)

Même avec les modifications décrites ci-dessus et après avoir reconstruit l’application, je vois l’avertissement de limite de débit dans la console du navigateur si j’active les blocs de la barre latérale droite.

Comment puis-je afficher ou déterminer la valeur réelle de, par exemple : DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL

De plus, si je désactive les blocs de la barre latérale droite, je ne vois aucun avertissement de limite de débit dans la console du navigateur si je parcours les sujets au même rythme qu’avec les blocs de la barre latérale droite activés.

Je suggère de chercher dans les discussions précédentes sur la limitation de débit.
Je ne suis pas un expert en la matière, mais si je comprends bien, la limitation de débit est appliquée en deux étapes : d’abord nginx effectue la limitation de débit (sans connaître les niveaux de confiance), puis l’application rails effectue une autre couche de protection.

Si vous souhaitez tester l’hypothèse selon laquelle vous rencontrez des limitations de débit au niveau de nginx, vous pouvez commenter la ligne suivante dans votre app.yml :

- templates/web.ratelimited.template.yml

Je n’ai aucune limite de débit définie dans le nginx que j’utilise comme proxy inverse, et j’essaierai ce que vous suggérez pour voir ce que fait le conteneur.

Je charge le classement, les meilleurs producteurs et les événements dans les blocs de la barre latérale droite.

Je ferai un retour, merci.

Je parie que vous avez raison, alors quels sont les bons mais plus souples valeurs pour ces paramètres dans /var/discourse/templates/web.ratelimited.template.yml ? Est-ce simplement par essais et erreurs ?

params:
reqs_per_second: 12
burst_per_second: 12
reqs_per_minute: 200
burst_per_minute: 100
conn_per_ip: 20

run:

  • replace:
    filename: “/etc/nginx/conf.d/discourse.conf”
    from: /server.+{/
    to: |
    limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;
    limit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;
    limit_req_status 429;
    limit_req_zone $binary_remote_addr zone=connperip:10m;
    limit_conn_status 429;

Je l’ai augmenté à :

reqs_per_second: 18
burst_per_second: 18
reqs_per_minute: 400
burst_per_minute: 200
conn_per_ip: 20

J’obtiens toujours le message “429 Too Many Requests”.

J’ai supprimé le classement, j’ai toujours le problème.

J’ai supprimé les blocs de la barre latérale droite, plus de problème :frowning: Très ennuyeux !

Ce n’est pas que je n’ai pas ce problème avec la barre latérale des meilleurs contributeurs.

Si vous travaillez à partir d’une adresse IP fixe, vous pourriez exclure votre adresse IP des limitations de débit :

Pour un premier test, je sauterais complètement la limitation de débit (il suffit de ne pas utiliser web.ratelimited.template.yml)

Vous pourriez trouver l’origine des requêtes en parcourant les journaux nginx :

 ./launcher enter app
less /var/log/nginx/access.log