DISCOURSE: Live-seurannan päivitysviive ruuhkahuipuissa

Yhteisö Kehitys
173

Queue timen ollessa >0.1 tipahtaa 429. Itsekin viime Tapparan pelissä huomasin että kaikki 429:t johtuivat >0.1 queue timestä (ne joiden mukana tuli performance headerinä tieto queue timestä).

Muistaakseni kun queue timeä säädettiin 0.3, niin siinä oli jokin sivuvaikutus että kyykkäsi isomminkin, mutta ehkä sitä nyt uskaltaisi taas koittaa nostaa kun on kannat eri raudalla?

Discoursen kehittäjien mukaan nuo “max reqs per ip” -rajat “eivät käytännössä ikinä ylity”, mutta jos tuolla ollut jotain vaikutusta niin sitä voisi koittaa jotenkin lokeista tutkia onko siellä tosiaan X IP:stä aikarajojen sisällä tosiaan niin monta pyyntöä että tuo limitti paukkuisi.

1 tykkäys
174

@ozzi @a1r6

Tässä on tosiaan melkoinen trappi vastassa, tai suorastaan sipulipuolustus. Sinänsähän nuo rajoittimet toimivat täysin oikein, eli sivusto ei kyykkää kokonaan vaikka millainen käyttävyöry osuisi kohdalle. Samaan aikaan rajoittimet ovat vähän liian agressiivisia, koska ne iskevät päälle pienestäkin aktiviteettipiikistä.

Yksisäikeisenä ajettu Redis meni tukkoon ja kun saatiin sopivasti Redis päivitys, joka mahdollisti multi-threading toiminnon, niin sitten alkoivat kuormat nousemaan korkeiksi.

Tästä seuraa read-only-tila, eli sivustoa aletaan näyttämään käyttäjälle kuten kirjautumattomalle, joka on nähdäkseni tosi huono UX. Tämä extreme load -rajoitin näyttää sekin perustuvan jonon pituuden seurantaan, eikä esimerkiksi CPU kuormaan.

Eli jos:

  1. Nostamme per IP rajoituksia, tai disabloimme ne kokonaan.
  2. Nostamme DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS -arvoa
  3. Mutta sitten pitäisi vielä päästä nostamaan tuota exteme load -rajoitinta, jotta Discourse sietäisi hetkellistä kuormaa ilman rajoittamista?

Meidän käyttötapauksessa aktiviteettipiikit ovat kuitenkin suht lyhyitä. Ensin tulee pelitilanteeseen perustuva piikki, ja tätä seuraa minuutin-parin ajan kohonnut aktiviteetti. Tämän jälkeen palaudutaan kuitenkin lähelle tilannetta edeltänyttä tasoa.

Poikkeus on pelit joissa turpaan tulee oikein kunnolla, sillä niissä varsin mielenkiintoisesti yleisaktiivisuus ja lukijoiden määrä nousee käytännössä loppupelin ajaksi.

1 tykkäys
175

Discoursea yhtään tuntematta, mitähän tämän laittaminen warn- tai none-asentoon mahtaisi tehdä:

# global rate limiter will simply warn if the limit is exceeded, can be warn+block, warn, block or none
max_reqs_per_ip_mode = block

En tiedä missä kaikkialla Discoursessa tuota rate limitingiä tehdään, mutta tuo extreme load päätyy rate_limit-funktioon, jossa heti kättelyssä tutkitaan tuo max_reqs_per_ip_mode:

def rate_limit(request)

if (
  GlobalSetting.max_reqs_per_ip_mode == "block" ||
  GlobalSetting.max_reqs_per_ip_mode == "warn" ||
  GlobalSetting.max_reqs_per_ip_mode == "warn+block"
)
1 tykkäys
176

Tuon nimenomaan diasabloin (taas) U20-pelin mainoskatkolla. Eli on nyt “none” ja kun kelaat viestiketjua ylemmäs, niin tuota on kokeiltu aikaisemminkin.

1 tykkäys
177

Taas yksi arvaus…

Kloonasin tuon discourse-repon niin pääsee hieman greppailemaan sorsia.

Suurin ongelma ilmeisesti on se, että poll-kutsusta tulee 429, joka aiheuttaa sen pitkän pätkäisyn.

Se taas ehkä liittyy tähän koodiin fileessä ./config/initializers/004-message_bus.rb:

  if queue_time = env["REQUEST_QUEUE_SECONDS"]
if queue_time > (GlobalSetting.reject_message_bus_queue_seconds).to_f
  raise RateLimiter::LimitExceeded, 30 + (rand * 120).to_i
end

end

Eli @ozzi:lla ja minulla pollin jälkeinen pätkäisy on vaihdellut sen 50s-150s välillä, ja tuo 30 + rand sopii nimenomaan siihen.

Eli pikaisella arvauksella reject_message_bus_queue_seconds tappiin niin ehkä poll-ongelmasta pääsee eroon.

Koodia lukemalla extreme load -limiterin pitäisi poistua tuolla jo kokeillulla max_reqs_per_ip_mode = none:lla

2 tykkäystä
178

Huomaa, että selaimet (luultavasti) reagoivat eri tavalla saatuaan 429:n, joka lisää todelliseen viiveeseen hajontaa.

1 tykkäys
179

Jep, mutta periaatteessa oireet sopisivat noihin kahteen parametriin eli kannattaisiko niitä seuraavassa livessä kokeilla vai mitä mieltä ihmiset ovat?

180

Kyllä tuota arvoa voisi nostaa. Huolissani olen vain tuosta extreme load - logged out -ominaisuudesta, joka on hyvin ärsyttävä.

1 tykkäys
181

Tämmöisellä sivustolla nuo 429:t eivät taida mennä selaimelle asti vaan sivua selaimessa pyörittävät skripit hoitavat ne.

182

Kysyin Discoursen Samilta, että onko olemassa ympäristömuuttujaa jolla voisimme vaikuttaa extreme load -rajoittimen raja-arvoon. Sain kerrassaan loistavan vastauksen, että yleensä sitä ei ole tarpeen muuttaa :man_shrugging:

Tämä nyt on tällaista nysväämistä, jolla tuskin saavutetaan lopullista voittoa, mutta voi silti yrittää hakea vähiten huonoa kompromissia. Yhdistelin tässä syksyn aikana kokeiltua ja opittua, jonka perusteella tuunasin parametrit asentoon jolla 429:iä saadaan vähennettyä, mutta jätetään serverin suojarajoittimet silti päälle. Ylikuormituksessa on riskinä extreme load -rajoitin, joka on loppukäyttäjälle kaikkein ikävin.

DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 400
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 100
4 tykkäystä
183

Nukahdin aamulla kesken Suomen pelin, mutta Chromessa oli Developer Tools käynnissä ja pelin aikana tuli yksi poll-requestin 429 ja siinä timeoutiksi oli arvottu 34 sekuntia.

2 tykkäystä
184

Ei yhtään 429:ä itselle tänään, mutta perjantain Tappara-matsi on tietenkin se kunnon testi.

1 tykkäys
185

Tänään ja huomenna on sitten viimeinen näytös sille, että onko tälle asialle omin neuvoin tehtävissä mitään.

U20-peleistä tuli todettua, että hyvin pieni keskustelijoiden joukko saa nykyään tuon 429:n aikaan. Kuvaavasti maaliskuussa onnistuimme viemään juuri KooKoota vastaan pelatun yleisöttömän matsin läpi, vaikka joku taisi mainita saaneensa extreme load -varoituksen.

Sellainen parannus on saatu aikaiseksi, että pystyn nyt säätämään asetuksia vain n. 30-60 sek palvelukatkoksella, eli hienosäätöä voidaan vielä tehdä vaikka erätauolla.

3 tykkäystä
186

No heti tuli ekasta Tapparan maalista.

poll-requestille 429, ja tämän x-queue-time oli 0.280087s.

Otteluseuranta: KooKoo - Tappara 8.1.2021 KLO 18
187

Onkohan tämä nyt sitten sama jono, jossa meillä on 0.2 raja-arvo? Tarvittaisiin enemmän pöhinää peliin, että näkee miten kurmitus käyttäytyy, ennen kuin nostaa raja-arvoa nykyisestä.

Extreme load -rajoitin on kuitenkin käyttäjän kannalta haitallisin.

188

Tuo mun mielestä on se 0.2-jono. Missään queue-timessä on ole nähnyt yli 0.3s-arvoa.

1 tykkäys
189

Taas tuli yksi, mutta mutta…

Se ei liittynyt live-seurantaan vaan Discourse haki muiden päivittyneiden ketjujen tietoja samaan aikaan ja se aiheutti 429:n live-seurantaan (tai varmaankin joka paikkaan, mutta tuon huomaa ainoastaan live-seurannassa). Discoursehan hakee taustalla kaikkia päivittyneitä, kun näyttää itselle tulleet notifikaatiot.

190

Sain yhden POLL 429:n kiinni 1-2 erien aikana. Kännykällä huomasin kerran käytännössä, että keskustelu pyshätyi.

Dokumentoidaan tännekin, että raja-arvo on nyt 0.3.

2 tykkäystä
191

Kolmas erä ilman 429:ä, mutta lopussa tuli pollista (queue time 0.332245) ja posts.jsonista (queue-time 0.597030).

Kun piikeissä tulee noin iso queue-time kuin posts.jsonista niin ei noita taida voida välttää muuta kuin nostamalla raja-arvoa tosi isoksi.

Edit. Itseasiassa tuo posts.json on eri ongelma, siinä arvotaan vain se 5-10 sekunnin paussi, poll on se jossa arvotaan 30-150 sekuntia ja tässä tapauksessa sekin oli vain tuo 0.3 eli seuraavaksi ehkä voisi kokeilla 0.4).

192

Sama tulos itsellä, ei yhtään POLLia. Kännykällä osallistuminen jäi vähän huonommaksi, mutta sen mitä ehdin niin ei jumeja.

3kpl jäi logiin noita posts.json 429 virheitä ja x-queue-timet minullakin 0.5…0.6 tietämissä.

Edit:

Livenä asetusten muuttaminen ja testaaminen on siitä ongelmallista, että keskustelun intensiteetti nousee luonnollisesti pelin loppua kohden. Viestejä yleensä vähiten 1. erässä.

1 tykkäys