Probleme beim Aktivieren des Components, vielleicht rechtsseitige Sidebar-Blöcke?

[sandra.mccollum]

Ich erhalte einige Fehler, haben Sie diese schon einmal gesehen und kennen Sie eine Lösung? Ich dachte, es wäre ein Windows-Speicherproblem, aber es tritt immer noch auf, wenn ich 6 GB unter Windows frei habe.

Beim Zurückkehren von einem Thema

Beim Aufrufen eines Themas:

Diese Fehler treten sporadisch auf, aber ziemlich oft

Danke für jeden Hinweis. Nicht, dass sie normalerweise erfolgreich sind, wenn ich es erneut versuche… Außerdem gibt es im /logs nichts darüber.

Beachten Sie, dass ich auch Featured Tiles hinzugefügt habe, aber wenn ich Right Sidebar Blocks deaktiviere, verschwindet das Problem. Ich habe 11 GB freien Speicher und viel Festplattenspeicher.

Wenn ich Featured Tiles deaktiviere und Right Sidebar Blocks aktiviere, besteht das Problem weiterhin.

[toanvoc (Toan Nguyen)]

Ich habe den gleichen Fehler wie du, aber ich weiß nicht, wie ich ihn beheben kann, obwohl ich ihn hier gepostet habe

[sandra.mccollum]

Hoffen wir, dass jemand eine Idee hat

[thoka (Thomas Kalka)]

Ich würde in der Browserkonsole nach Fehlern suchen.

[sandra.mccollum]

Ich habe 1100 Zeilen zurückbekommen, hier ist ein Teil davon:

2 deprecation-identify-source.js:15 DEPRECATION: Komponenten mit separat aufgelösten Vorlagen sind veraltet. Migrieren Sie entweder zu gemeinsam genutzten js/ts + hbs-Dateien oder zu gjs/gts. Versuch, ‘template:components/top-contributors’ nachzuschlagen. [deprecation id: component-template-resolving] Dies wird in ember-source 6.0.0 entfernt. Siehe Component Template Resolving | Ember.js - Deprecations

post.js:561 Verwende das neue ‘glimmer’-Postmenü!
2deprecation-identify-source.js:15 DEPRECATION: Komponenten mit separat aufgelösten Vorlagen sind veraltet. Migrieren Sie entweder zu gemeinsam genutzten js/ts + hbs-Dateien oder zu gjs/gts. Versuch, ‘template:components/top-contributors’ nachzuschlagen. [deprecation id: component-template-resolving] Dies wird in ember-source 6.0.0 entfernt. Siehe Component Template Resolving | Ember.js - Deprecations

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Zu viele Anfragen)

Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 DEPRECATION: Komponenten mit separat aufgelösten Vorlagen sind veraltet. Migrieren Sie entweder zu gemeinsam genutzten js/ts + hbs-Dateien oder zu gjs/gts. Versuch, ‘template:components/whos-online’ nachzuschlagen. [deprecation id: component-template-resolving] Dies wird in ember-source 6.0.0 entfernt. Weitere Details finden Sie unter Component Template Resolving | Ember.js - Deprecations.

[thoka (Thomas Kalka)]

@sandra.mccollum

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Too Many Requests)

Das könnte die Ursache sein. In diesem Fall sind Sie wahrscheinlich Raten-begrenzt.
Sie könnten den Netzwerk-Tab der Entwicklerkonsole überprüfen, ob es mehr Anfragen gibt, wenn die rechten Seitenleisten-Blöcke aktiviert sind.

[sandra.mccollum]

Eine Frage, falls jemand Bescheid weiß:

(1) Ich bin ein Administrator, Vertrauensstufe 4, warum umgeht mich “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” nicht für irgendeine Ratenbegrenzung?

Available settings for global rate limits and throttling

Discourse ships with 3 different global rate limits that can be configured by site admins. Global per-ip rate limits These limits apply to every unique IP address that hits the Discourse application. (files that are served directly from the filesystem or the CDN are excluded) By default this rate limit is enabled, you may disable it or set it to a reporting mode. DISCOURSE_MAX_REQS_PER_IP_MODE : default block, this rate limit applies out of the box. (other options are warn, warn+block, and n…

Globale IP-bezogene Ratenbegrenzungen
Diese Limits gelten für jede eindeutige IP-Adresse, die auf die Discourse-Anwendung zugreift. (Dateien, die direkt vom Dateisystem oder dem CDN ausgeliefert werden, sind ausgeschlossen)

Standardmäßig ist diese Ratenbegrenzung aktiviert. Sie können sie deaktivieren oder in den Berichtsmodus versetzen.

DISCOURSE_MAX_REQS_PER_IP_MODE: Standardmäßig blockieren, diese Ratenbegrenzung gilt sofort. (andere Optionen sind warn, warn+block und none)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: Anzahl der Anfragen pro IP pro Minute (Standard ist 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: Anzahl der Anfragen pro IP pro 10 Sekunden (Standard ist 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: Anzahl der Asset-Anfragen (Avatare/CSS) pro IP pro 10 Sekunden (Standard ist 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: Soll die Ratenbegrenzung für private IPs gelten, die auf Discourse zugreifen? Standard ist false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: Verwenden Sie pro Benutzer Ratenbegrenzungen anstelle von IP-Ratenbegrenzungen für Benutzer mit dieser Vertrauensstufe oder höher (Standard 1)

Um die Limits zu ändern, fügen Sie die gewünschte Änderung in Ihre app.yml-Datei im Abschnitt env ein.

Ich werde vielleicht versuchen:

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

Ich habe auch das Nginx-Zugriffslog überprüft, es zeigt unterschiedliche IPs für unsere Benutzer an. (Ich habe in einem viel früheren Thema gesehen, wo dies ein Problem war, alle benutzten dieselbe IP-Adresse für den Zugriff)

[sandra.mccollum]

Selbst mit den oben beschriebenen Änderungen und nach dem Neuerstellen der App sehe ich die Warnung vor der Ratenbegrenzung in der Browserkonsole, wenn ich die Blöcke der rechten Seitenleiste aktiviere.

Wie gebe ich den tatsächlichen Wert von z. B. DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL aus oder ermittle ihn anderweitig?

Wenn ich die Blöcke der rechten Seitenleiste deaktiviere, sehe ich auch keine Warnungen vor der Ratenbegrenzung in der Browserkonsole, wenn ich Themen mit der gleichen Geschwindigkeit durchlaufe wie mit aktivierten Blöcken der rechten Seitenleiste.

[thoka (Thomas Kalka)]

Ich schlage vor, in der Suche nach früheren Diskussionen über Ratenbegrenzung zu suchen.
Ich bin in diesem Thema nicht tiefgründig, aber meines Verständnisses nach wird die Ratenbegrenzung in zwei Stufen angewendet: zuerst macht nginx Ratenbegrenzung (ohne Kenntnis der Vertrauensstufen) und dann bietet die Rails-App eine weitere Schutzschicht.

Wenn Sie die Hypothese testen möchten, dass Sie innerhalb der Nginx-Schicht auf Ratenbegrenzungen stoßen, können Sie die folgende Zeile in Ihrer app.yml auskommentieren:

- templates/web.ratelimited.template.yml

[sandra.mccollum]

Ich habe keine Ratenbegrenzungen in meinem Nginx-Reverse-Proxy eingestellt und werde versuchen, was Sie vorschlagen, um zu sehen, was der Container tut.

Ich lade Leaderboard, Top Producers und Events in den Right Sidebar Blocks.

Ich melde mich wieder, danke.

Ich wette, Sie haben Recht. Was sind also gute, aber lockerere Werte für diese Einstellungen in /var/discourse/templates/web.ratelimited.template.yml? Ist es einfach Ausprobieren?

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;

Ich habe es erhöht auf:

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

Ich erhalte immer noch die Meldung “429 Too Many Requests”.

Ich habe Leaderboard entfernt, erhalte aber immer noch das Problem.

Ich entferne die Right Sidebar Blocks, kein Problem mehr Sehr ärgerlich!

Nicht, dass ich dieses Problem nicht auch mit der Top Contributors Sidebar habe.

[thoka (Thomas Kalka)]

Wenn Sie von einer festen IP-Adresse aus arbeiten, könnten Sie Ihre IP von der Ratenbegrenzung ausschließen:

Available settings for global rate limits and throttling

It looks to me like if you have the web.ratelimited.template.yml installed, then these don’t matter since stuff gets rate limited by NGINX before it gets to Discourse, right? That’s how it seems from my nginx logs. My short term solution is to add my IP address to the local IP list, so it gets past NGINX. I guess the thing to do is remove the ratelimited template to make these have any meaning?

Für einen ersten Test würde ich die Ratenbegrenzung komplett überspringen (verwenden Sie einfach nicht web.ratelimited.template.yml)

@sandra.mccollum

Ich wette, Sie haben Recht, also was sind gute, aber lockerere Werte für diese Einstellungen in /var/discourse/templates/web.ratelimited.template.yml? Ist es einfach Versuch und Irrtum?

Sie könnten den Ursprung der Anfragen durchsuchen der Nginx-Logs finden:

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