Jos kehittäjät eivät tuohon vielä ennen seuraavaa pelipäivää saa selvyyttä, niin kokeile vielä sellaista että pistät nollat sisäisen rate limiterin arvoihin perään. Discoursen asennushakemistossa kun heilauttaa launcherilla Discoursen containeriin sisään (sudo ./launcher enter app):
Discoursessa olisi myös vaihtoehtona “max_reqs_per_ip_mode = warn”, (oletuksena se on “block”), mutta ehkä se on selkeintä vain kokeilla isonnetuilla arvoilla. Varsinkin jos sisäisessä rate limiterissä on jonkinlaista bugia.
Tämä sisäinen rate limiter on nähdäkseni täysin erillään web.ratelimited -templatesta (mikä taitaa vaikuttaa pelkästään Nginxin asetuksiin), joten siinä mielessä sisäisen rate limiterin toimintaa voisi olla hyvä hieman twiikata ja katsoa miten käy.
Tekisi melkein mieli sanoa että jos hidastelut eivät johdu näistä 429 vastauksista, niin ostan Ipan mukin
Kyllä ne todennäköisesti johtuvat, koska 429 laittaa selaimen vaihtelevan mittaiselle tauolle. @ozzi:kin analysoi perjantain peliä ja 429:t korreloivat jumien kanssa. Se myös selittää miksi kokemus vaihtelee per selain/käyttäjä.
Kokeillaan tuotakin.
@Spartak Casen outous piilee siinä, että mikään ei ole keväästä muuttunut (paitsi Discoursen versio) ja emme pääse lähellekään samaa palvelukykyä.
Tein salapoliisin työtä ja nyt saattoi tärpätä! Rate Limiting -toiminto on ollut oletuksena Disabled, mutta Huhtikuussa kehittäjät ovat kääntäneet sen asentoon Enabled. Aikana paljastuu muokkauspäivämäärästä Metassa olevasta wiki-ohjeistuksesta.
Tappara pelasi viimeiseksi jääneen KooKoo matsin tyhjässä hallissa 12.03. Tämän jälkeen live-seurannan aiheuttamaan “painetta” ei ole ollut, ennen Tampere Cuppia. Kaksi edellista Discoursen Major -päivitystä osuivat off-seasonille, eli 2.4 päivitetiin 21.03 ja versio 2.5 laitettiin 11.08 (ns. talvirenkaat ).
Luultavasti siis 2.5 version päivitys on kääntänyt Rate Limited -toiminnon päälle, kun taas edelliset kaudet on pelattu asennossa Disabled. Eli jos väännämme sen asentoon Disabled, saattaisimme päästä tilanteeseen jossa olimme maaliskuussa. (Olettaen ettei jotain muita muutoksia ole uinut vaivihkaa sisään).
Se tosin epäilyttää, että perjantaina kokeilimme jo melko isoja arvoja tuohon rajoittimeen. Ne ehkä auttoivat vähän, mutta edelleen jumituksia havaittiin.
Se tosin epäilyttää, että perjantaina kokeilimme jo melko isoja arvoja tuohon rajoittimeen. Ne ehkä auttoivat vähän, mutta edelleen jumituksia havaittiin.
Tämä ei ole ihan yksioikoista, sillä käsittääkseni nuo perjantaina tehdyt muutokset vaikuttavat pelkästään Nginxin rate limiteihin, mutta ei mitenkään Discoursen “sisäisiin rate limitteihin”. Itsellä on sellainen karkea perstuntuma että ongelmaa aiheuttaa juuri tämä sisäisen rate limitin toiminta (max_reqs_per_ip_per_minute jne), syystä tai toisesta. Jos sinne täräyttää huomattavasti isommat parametrit, niin sillä ainakin saa vähän haarukoitua missä kohtaa rupeaa menemään metsään.
Toinen mitä myös jossain kohtaa olisi hyvä koittaa niin olisi laittaa toiminto pelkästään “warn” siihen mitä tapahtuu kun tämä sisäinen rate limit paukkuu punaiselle (oletuksena se on “block” mikä aiheuttanee nykyisen havaitun laisen toiminnan). Ja jos jotenkin mahdollista että koko sisäisen rate limitin saisi offille, niin siinäkin olisi yksi hyvä kokeilun paikka.
Ohjeistus on aavistuksen sekava tältä osin. En hahmota miten palautan tilanteen joka oli ennen Huhtikuuta. web.ratelimited.template.yml on ollut kuitenkin mukana jo vanhemmissakin versioissa.
20.04 tehty muokkaus:
By default this rate limit is disabled , but we are considering enabling it out of the box.
By default this rate limit is enabled , you may disable it or set it to a reporting mode.
Asetusten sörkkiminen containerin sisällä on tietysti yksi tapa debugata, mutta containerihan rakennetaan uusiksi jokaisessa päivityksissä. Ja koska tämä värkki on ennen toiminut hyvin, niin lähtökohtaisesti pitää hakea korjausta admin-rajapinnasta.
Näyttäisi että sisäisen rate limitin asetuksia ei pysty muuttamaan hallintapaneelin kautta. Niitä varmaan pidetään sen verran rajatapauksina että ei ole kunnon käyttöliittymää niiden muokkaamiseen.
Containerin sisällä config-kansiossa on discourse_defaults.conf missä on iso läjä asetuksia, siinä heti alkuun sanotaan “NOT EDIT THIS FILE If you need to make changes create a file called discourse.conf in this directory with your changes”. Tuon perusteella discourse.confiin voi huoletta rukata asetuksia ilman pelkoa että ne rebuildissa katoaa.
Jos tarvetta jotain muutakin rukata niin tarvittavat asetusrivit voi kopioida discourse_defaults.confista ja täräyttää discourse.confiin.
Jees, admin rajapinnalla tarkoitinkin .yml tiedostoja, jotka on tarkoitettu muokattavaksi.
DISCOURSE_MAX_REQS_PER_IP_MODE: none
Tuo on nyt valmiiksi konffattuna ja polkaisen rebuildin ennen seuraavaa peliä, jonain hiljaisena hetkenä. Samalla palaan default asetuksiin, eli poistan erilaiset virittelyt jolla tätä on yritetty taklata (unicornit, db bufferit).
Sinänsä throttlaus on varsin perusteltua, sillä jos paikalle osuu esim. huonosti käyttäytyvä botti (ainakin Bing hakukoneen on ollut ennen sellainen), niin se imaisee nämä kaikki sivut 100% vauhdilla ja kyykyttää serveriä sitä tehdessään. Toisaalta ei tämä ole ollut ongelma 2016-20 ja CloudFlarekin mahdollisesti antaa jotain suojaa.
Keskiviikkona taitaa olla matsi. Ans kattoo mitä tapahtuu.
Tätä keissiä on maallikon näkökulmasta mukava seurata vaikka olenkin osa ongelmaa ja tavallaan yksi turhautunut käyttäjä muiden joukossa. Mutta jumakekka että täällä löytyy tietoa ja hyviä arvauksia ja testausta. Tsemppiä teille, toivottavasti natsaa ja saadaan k.o. vika / feature / bug crushattua.
@Spartak:in tutkimukset ovat antaneet todella arvokkaita johtolankoja. Saattaa tulla yllätyksenä (tai sitten ei), mutta minähän en ole sysadmin hommissa kuin korkeintaan valistunut puuhastelija, joka osaa lukea (hyvin kirjoitettuja) ohjeita. Ne on ihan muut kaverit jotka ovat oikeita ammattilaisia. Vanhalla foorumilla serveriasiat hoiti itse asiassa kaveri, joka oli yksi Suomen parhaita. Ennen koronaa hän eli start-up elämää ja pyöri Amerikassa projektiaan pitchaamassa. Toisaalta tekemällä, ja vain tekemällä, oppii.
Nettisivujen pystyttäminen on tänä päivänä tosi helppoa. Koulutettu simpanssi osaisi asentaa Discoursen. Mutta sitten kun koko kasvaa, tai ongelmia ilmenee niin ylämäki jyrkkenee. Jos kasvu jatkuu, niin jossain kohtaa tämä saattaa mennä tosi haastavaksi ja myös kalliiksi.
Siellä on nyt fiksi kehityshaarassa ja tulee mukaan seuraavaan beettaversioon. Seuraava stable on tulossa joulukuussa.
En osaa arvioida onko Samin fiksi hyvä.
Kokeillaan huomenna miten tämä värkki toimii kun disabloin ratelimiter-ominaisuuden kokonaan. Laitan myöhemmin tänään Purkkaviritys™ v3:sen tulille.
Jos homma toimii hienosti, niin voidaan harkita kahta vaihtoehtoa
Mennäänkö näillä jouluun
Vai otetaanko beta versio vähäksi aikaa tuotantoon. Voimme palata stable haaraan joulukuussa. Käyttöliittymän modaukset pitäisi testata. Olisi toisaalta hyvä testata beta, koska se avaisi mahdollisuuden antaa palautetta Samin korjauksesta. Stable versioon on aikaa, joten palautteen perusteella olisi mahdollista saada jatkokehitystäkin.
Discourse-tiimi itse ottaa tuotantoon ja testaa sitä osaltaan, mutta heillä on huomattavan erilainen ja järeämpi infrastruktuuri.
Mä en oo aikoihin ehtinyt tehdä käännöstyötä, joten kaikki beta-version uutuudet on kääntämättä. Mutta kannatan beta-versiota silti. Voin yrittää kääntää kriittisimmät jutut, kun sattuu olemaan tällä viikolla selvästi enemmän vapaa-aikaa kuin on viime aikoina ollut.
No niin, tämän pitäisi nyt olla tulilla. Huomenna nähdään sitten mahdolliset vaikutukset. Tosiaan, ei riitä kooditason ymmärrys onko tämä ratkaisu ongelmaan, sillä varsinainen fiksi on huomattavasti monimutkaisempi.
Mutta pelaamalla se selviää. Toivottavasti tulisi taas sellainen railakas Sport-peli, jotta live-seuranta kiihtyy testitarpeisiin riittävästi
Semmoinen koodimuutos tästä vielä pistää silmään, että eihän Discoursen versio ollut 2.3.x (tai vanhempi) silloin kun homma viimeksi pelasi? 2.4 versiossa lisättiin “reject_message_bus_queue_seconds” (mikä on oletuksena 0,1 sekuntia), mikä myös sopisi aika hyvin oireisiin.
if a message bus request queues for 100ms or longer, we will reject it and ask consumer to back off
reject_message_bus_queue_seconds = 0.1
Itse asiassa nyt kun sanoit, kyllä. Tässä ketjussa on syytetty edellistä Discouse-päivitystä, mutta on niin, että asennettiin kausien välisellä tauolla peräti kaksi isoa päivitystä. Nykyinen 2.5 asennettiin 11. elokuuta, mutta syyllinen voi yhtä hyvin olla 24. maaliskuuta asennettu versio 2.4.
Juu, oletus oli ratelimiter toiminnallisuudessa, joka tuli 2.5:ssa. Molemmat kuitenkin asennettiin viime kauden jälkeen, eli 2.3 on edellinen joka todistetusti toimii.
Loistavaa! Sitten tässä on yksi selkeä kandidaatti mikä saattaa olla ongelman takana ja mitä voisi koittaa säätää. reject_message_bus_queue_seconds esim. asetukselle 0.2 tai 0.3.
Tuo “messagebus suojaus” palauttelee 429:jä jos systeemiltä kestää > 0.1 sekuntia käsitellä pyyntöä. Piikin aikana voisi olettaa että tämä on hyvinkin mahdollista.
Käsittääkseni se pitäisi siis environmentiin lisätä jotenkin näin: DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2
Tuohon on tulossa seuraavassa versiossa tosiaan “fiksiä”. Siinä kun serveri pyytää clienttiä jarruttamaan, client jäähdyttelee 5-10s ja yrittää sitten uudestan. En tiedä miten tuo näkyy sitten liveseurannassa, pamahtaako sieltä sitten kymmeniä viestejä kerralla 10s viiveen jälkeen?
Mutta tuota mainitsemaasi arvoa voisi tosiaan koittaa kasvattaa, ei tosin mitään hajua millaisia ne viiveet jonossa voi olla. Ainakaan serverin kuorma ei ole lähelläkään kattoa vielä.
).