Problemi quando attivo Component, forse i Blocchi della Barra Laterale Destra?

[sandra.mccollum]

Sto riscontrando alcuni errori, li hai già visti e conosci qualche soluzione? Pensavo fosse un problema di memoria di Windows, ma continua a verificarsi anche se ho 6 GB liberi in Windows.

Al ritorno da un argomento

Andando su un argomento:

Questi errori sono intermittenti, ma si verificano abbastanza spesso

Grazie per qualsiasi suggerimento. Da notare che se riprovo, di solito funzionano… Inoltre, non c’è nulla a riguardo in /logs

Nota che ho anche aggiunto Featured Tiles, ma se disabilito Right Sidebar Blocks, il problema scompare. Ho 11 GB di memoria libera e spazio su disco in abbondanza.

Se disabilito Featured Tiles e abilito Right Sidebar Blocks, il problema persiste.

[toanvoc (Toan Nguyen)]

Ho lo stesso errore tuo ma non so come risolverlo anche se l’ho postato qui

[sandra.mccollum]

Speriamo che qualcuno abbia un’idea

[thoka (Thomas Kalka)]

Cercherei nella console del browser eventuali errori.

[sandra.mccollum]

Ho ricevuto 1100 righe, eccone una parte:

2 deprecation-identify-source.js:15 DEPRECATION: I componenti con template risolti separatamente sono deprecati. Esegui la migrazione a file js/ts + hbs co-locati o a gjs/gts. Tentativo di lookup di ‘template:components/top-contributors’. [id deprecazione: component-template-resolving] Questo verrà rimosso in ember-source 6.0.0. Vedi Component Template Resolving | Ember.js - Deprecations

post.js:561 Utilizzo del nuovo menu post ‘glimmer’!
2deprecation-identify-source.js:15 DEPRECATION: I componenti con template risolti separatamente sono deprecati. Esegui la migrazione a file js/ts + hbs co-locati o a gjs/gts. Tentativo di lookup di ‘template:components/top-contributors’. [id deprecazione: component-template-resolving] Questo verrà rimosso in ember-source 6.0.0. Vedi Component Template Resolving | Ember.js - Deprecations

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

Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 DEPRECATION: I componenti con template risolti separatamente sono deprecati. Esegui la migrazione a file js/ts + hbs co-locati o a gjs/gts. Tentativo di lookup di ‘template:components/whos-online’. [id deprecazione: component-template-resolving] Questo verrà rimosso in ember-source 6.0.0. Vedi Component Template Resolving | Ember.js - Deprecations per maggiori dettagli.

[thoka (Thomas Kalka)]

@sandra.mccollum

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

Questa potrebbe essere la causa. In questo caso, probabilmente sei limitato dalla frequenza delle richieste.
Potresti controllare la scheda di rete della console per sviluppatori, se ci sono più richieste, quando i blocchi della barra laterale destra sono abilitati.

[sandra.mccollum]

Una domanda se qualcuno lo sa:

(1) Sono un amministratore, livello di fiducia 4, quindi perché “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” non mi esenta da alcun limite di frequenza?

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…

Limiti di frequenza globali per IP
Questi limiti si applicano a ogni indirizzo IP univoco che raggiunge l’applicazione Discourse. (i file serviti direttamente dal filesystem o dalla CDN sono esclusi)

Per impostazione predefinita, questo limite di frequenza è abilitato, puoi disabilitarlo o impostarlo in modalità di segnalazione.

DISCOURSE_MAX_REQS_PER_IP_MODE: blocco predefinito, questo limite di frequenza si applica immediatamente. (altre opzioni sono avvisa, avvisa+blocca e nessuna)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: numero di richieste per IP al minuto (il valore predefinito è 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: numero di richieste per IP ogni 10 secondi (il valore predefinito è 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: numero di richieste di asset (avatar/css) per IP ogni 10 secondi (il valore predefinito è 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: il limite di frequenza dovrebbe applicarsi agli IP privati che accedono a Discourse? il valore predefinito è false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: utilizzare limiti di frequenza per utente anziché limiti di frequenza per IP per gli utenti con questo livello di fiducia o superiore (predefinito 1)

Per modificare i limiti, aggiungi la modifica desiderata al tuo file app.yml nella sezione env.

Potrei provare:

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

Ho anche controllato il log degli accessi di nginx, mostra IP diversi per i nostri utenti. (Ho visto in un argomento molto precedente in cui questo era un problema, tutti usavano lo stesso indirizzo IP per l’accesso)

[sandra.mccollum]

Anche con le modifiche descritte sopra e dopo aver ricompilato l’app, vedo l’avviso del limite di frequenza nella console del browser se abilito i blocchi della barra laterale destra.

Come posso visualizzare o determinare in altro modo il valore effettivo di, ad esempio: DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL

Inoltre, se disabilito i blocchi della barra laterale destra, non vedo alcun avviso del limite di frequenza nella console del browser se navigo tra gli argomenti alla stessa velocità con cui lo faccio con i blocchi della barra laterale destra abilitati.

[thoka (Thomas Kalka)]

Suggerisco di cercare discussioni precedenti sul rate limiting.
Non sono esperto in questo argomento, ma per quanto ne so, il rate limiting viene applicato in due fasi: prima nginx esegue il rate-limiting (senza conoscere i livelli di fiducia) e poi l’applicazione rails esegue un altro livello di protezione.

Se desideri testare l’ipotesi che incontri limiti di frequenza nello strato nginx, puoi commentare la seguente riga nel tuo app.yml:

- templates/web.ratelimited.template.yml

[sandra.mccollum]

Non ho limiti di frequenza impostati in nginx, che uso come proxy inverso, e proverò quello che suggerisci per vedere cosa sta facendo il container.

Sto caricando Leaderboard, Top Producers ed Events nei blocchi della barra laterale destra.

Riporterò, grazie.

Scommetto che hai ragione, quindi quali sono valori buoni ma più permissivi per queste impostazioni in /var/discourse/templates/web.ratelimited.template.yml? È semplicemente per tentativi ed errori?

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;

L’ho aumentato a:

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

Ottengo ancora il messaggio “429 Too Many Requests”.

Ho rimosso Leaderboard, ottengo ancora il problema.

Ho rimosso i blocchi della barra laterale destra, nessun altro problema Molto fastidioso!

Non che non abbia questo problema con la barra laterale dei Top Contributors.

[thoka (Thomas Kalka)]

Se lavori da un IP fisso, potresti escludere il tuo IP dal rate limiting:

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?

Per un primo test, eviterei completamente il rate limiting (basta non usare web.ratelimited.template.yml)

@sandra.mccollum

Scommetto che hai ragione, quindi quali sono valori buoni ma più permissivi per queste impostazioni in /var/discourse/templates/web.ratelimited.template.yml? È semplicemente per tentativi ed errori?

Potresti trovare l’origine delle richieste sfogliando i log di nginx:

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