Di tanto in tanto riceviamo questa notifica in cima al nostro forum:
A causa di un carico estremo, questo viene temporaneamente visualizzato a tutti come lo vedrebbe un utente non autenticato.
Ho alcune osservazioni e domande al riguardo:
Innanzitutto, il server non sembra essere sotto un carico estremo. L’ultima volta che ho visto l’avviso, il monitoraggio del server ha mostrato che il carico della CPU ha raggiunto un picco del 24%, l’utilizzo della memoria era appena superiore al 50%, ecc. Per quanto ne so, non ci sono state diminuzioni percettibili delle prestazioni per gli utenti. Quindi mi chiedo: qual è la soglia per questo avviso ed è ragionevolmente calibrata?
In secondo luogo, e più importante per me, il forum che gestisco è completamente privato. Gli utenti non autenticati non possono vedere nulla tranne la pagina di accesso. Quindi la notifica è errata, ovvero la pagina non viene visualizzata come la vedrebbe un utente non autenticato, perché un tale utente non potrebbe vederla affatto. Questo ha creato confusione alcune volte perché è stato interpretato come se i post del nostro forum privato fossero improvvisamente disponibili per utenti non autorizzati. Sono stato io stesso piuttosto allarmato la prima volta che l’ho visto e di tanto in tanto ricevo domande dagli utenti al riguardo.
Forse questo avviso dovrebbe essere riscritto? O modificato/disabilitato per i forum privati?
La ricerca di questo cookie su GitHub restituisce:
Dove force_anon si trova qui:
def initialize(app, settings = {})
@app = app
end
def call(env)
helper = Helper.new(env)
force_anon = false
if helper.should_force_anonymous?
force_anon = env["DISCOURSE_FORCE_ANON"] = true
helper.force_anonymous!
end
Riferimento:
Vedi anche:
MIN_TIME_TO_CHECK = 0.05
ADP = "action_dispatch.request.parameters"
def should_force_anonymous?
if (queue_time = @env['REQUEST_QUEUE_SECONDS']) && get?
if queue_time > GlobalSetting.force_anonymous_min_queue_seconds
return check_logged_in_rate_limit!
elsif queue_time >= MIN_TIME_TO_CHECK
if !logged_in_anon_limiter.can_perform?
return check_logged_in_rate_limit!
end
end
end
false
end
Questo avviso viene visualizzato se NGINX inoltra una richiesta a Unicorn (il server dell’applicazione) e rileviamo un ritardo significativo.
Ad esempio (esagerato):
NGINX dice: “Ehi, ecco una richiesta ricevuta da un utente alle 13:00”
Passa un’ora
Il server dell’applicazione riceve la richiesta: “Accidenti, ci è voluto un’ora per riceverla… devo essere sovraccarico.”
È possibile controllare la soglia con queste due impostazioni:
DISCOURSE_FORCE_ANONYMOUS_MIN_QUEUE_SECONDS e DISCOURSE_FORCE_ANONYMOUS_MIN_PER_10_SECONDS
Soprattutto, se il tuo server ha molta capacità aggiuntiva, aggiungi più processi Unicorn aumentando UNICORN_WORKERS.
Se un sito richiede l’accesso, allora credo che dovremmo cambiare l’avviso in qualcosa di più severo (schermata blu, sei limitato in termini di frequenza delle richieste).
È la prima volta che sento di un sito che richiede l’accesso e che ha raggiunto questo limite di frequenza. Concordo sul fatto che dovremmo fare un po’ meglio in questo caso.
Il meglio che possiamo fare sotto carico estremo, per i siti che “richiedono l’accesso”, è semplicemente mostrare una schermata blu con la scritta “sito sovraccarico, riprova più tardi”. Vorrei attendere un po’ prima di aggiungere questa funzionalità e vedere un altro reclamo.
Sto accadendo in una piccola comunità privata Discourse che frequento spesso. Mi ha restituito un errore 502 bad gateway nginx, dopodiché non si è più caricata. Alla fine si è caricata, ma ha mostrato il messaggio del banner sopra menzionato.