Käytännössä koko kolmannen erän minkä ehdin seurata, oli posts.json pyyntöihin queue time melkolailla aina välillä 0.2x - 0.3x. Silloin kun meni >0.5x niin tuli 429. Näitä oli kolme:
x-queue-time: 0.525667
x-queue-time: 0.528161
x-queue-time: 0.503082
Message busista näkyi kaksi 429:ä (harmi että onnistuneista pyynnöistä ei palaudu queue timeä):
x-queue-time: 0.359486
x-queue-time: 0.330240
En ymmärrä - onko tässä nyt sitten joku eri raja-arvo, jos kerran >0.5 triggeroi 429:n?
Täsmälleen sama havainto, mutta posts.json ei ole niin iso ongelma, kun siinä arvotaan vain se 5-10 sekunnin paussi, message-busista se 30-150 sekuntia.
Mutta tämän päivän havaintojen perusteella raja-arvon nostaminen 0.4:ään pitäisi auttaa.
Täytyy olla, ilmeisesti se 0.3 on (ainoastaan?) message busiin vaikuttava asetus.
Ja sitten kun vielä löytyisi mistä tuota 0.5 sekunnin rajaa saa nostettua, epäilen että siinä ei pannu kärähdä vaikka sitäkin nostaisi 
Se message-bus-asetus on tämä:
En ole tutkinut tuota posts.json-koodia, kun se ei aiheuta niin isoa ongelmaa.
Eilen puolen yön aikaan laitoin raja arvoksi 0.4.
Toinen juttu mikä alkoi kiinnostamaan, on SQL ja Redis-latenssien suhde. Se on SQL:ssa ollut paljon korkeampi, mutta toki operaatiotkin erilaisia.
Mietin että pitäisikö Redis threadien määrä pudottaa 3->2, joka vapauttaisi vähän jerkkua tietokannan pyörittämiseen?
Itse tekisin vain yhden muutoksen kerralla, jotta voi paremmin arvioida sen vaikutusta ja jatkaa sitten hienosäätöä tulosten pohjalta.
Ehdottomasti.
Data-serverin muljautus aiheuttaisi pidemmän katkoksenkin.
Ja nyt erätauolla 0.5
Mikäs nyt on suunnitelma todennäköiseen torstain SaiPa-matsiin?
0.4 toimi hyvin, mutta ei täydellisesti, 0.5 taas paukautti rate limiterin.
Rate limiterit kokonaan pois vai parametreja suuremmiksi?
Eilen meni vähän mittailut pieleen, sillä kun Jukurit alkoivat kääntämään peliä, tuli aivan älytön kävijöiden vyöry. Selvästi 0.5 on liian korkea, koska alkoi tulemaan tuota extreme loadiakin – rajoittimien tarkoitus on kuitenkin nimenomaan suojella, eli tarvittaessa rajoittaa.
Eilen on tullut test-passed haaraan committi, jonka yksi kehittäjistä sanoi olevan merkittävä meidän tyyppisessä käyttötapauksessa.
Jotta se saataisiin mukaan, niin sitten pitäisi taas päivittää tuohon epävakaaseen koodihaaraan, eli samalla tulisi koko joukko muitakin committeja.
Comments @ozzi?
Jos tässä puhuttiin siitä aiemmin mainitsemastani jonon odotusrajasta, niin se on background_requests_max_queue_length muuttuja.
@ljpp tuo muutos käyttää “topic tracking state” viestit jonojen kautta, eikä yritä tehdä niitä suoraan. En tiedä riittävästi Discoursen sielunelämästä sanoakseni miten tuo vaikuttaa kokonaisuuteen.
Olemme nyt sitten tests-passedissa ja siten tämä muutos on sisässä. Huomenna nähdään vaikuttiko se mitään.
En koskenut Redis-threadien määrään, koska ajattelin että on viisainta edelleenkin tehdä yksi muutos kerrallaan.
@a1r6 ja muut.
429 lokitus antaa taas tänään ehkä jotain lisätietoa toiminnasta ja tulokset kiinnostaa ainakin ylätasolla. Itse en ole kovin optimistinen tämän viimeisimmän fiksin vaikuttavuuteen, mutta kehittäjät pitivät sitä merkittävänä. Jos se vaikuttaa logiikkaan jolla taskeja jonotetaan, niin voihan tuosta hyötyäkin olla – Redis ei vaan mielestäni ole ollut mikään pullonkaula, tai en ole ainakaan sellaisesta löytänyt näyttöä.
Katsellaan mitä sieltä tulee. Paljonhan se on kiinni siitä millainen matsi on ja tapahtuuko siinä jotain poikkeuksellista ja/tai poikkeuksellisen ikävää. Negatiiviset tilanteet nostavat paitsi viestien määrää, myös hiljaisten sivustaseuraajien aktiivisuus näkyy nousevan jopa 100% (viime peli). Koronaefektiäkin selkeästi, kun kukaan ei ole hallilla. Ehkä siellä ei yhtä herkästi tulla somettamaan kesken pelin kuin kotisohvalla.
Itsellä on tuossa henkilökohtainen meno ja tekee tiukkaa ehtiä pelin alkuun. Onneksi luonnonlakina aktiivisuus lisääntyy mitä pidemmälle pelataan.
Mulla tuo jumi ei tainnut taas liittyä live-ketjuun, kerran aiemmin törmännyt samaan, siinä pelissä keskellä erätaukoa.
Eli, tämmöinen get-request:
xhttps://tappara.co/t/20085/3274.json?track_visit=true&forceLoad=true
Ja tuo URL on oma postaukseni, johon ehkä tuli tykkäys tms:
Tuosta getistä tuli sitten response, jonka koko oli 123.6KB ja näyttäisi sisältävän esim. todella paljon erilaisia id:tä:
“stream”:[todella monta id:tä…].
Tuon x-queue-time oli 0.447143, mutta tuosta status code 200.
Mutta, heti tuon jälkeinen poll tuotti 429 x-queue-time:llä 0.418496.
Ei mitään käsitystä, että mitä kaikkea tuo edellinen response sisältää, mutta alkaa näin:
{“post_stream”:{“posts”:[{“id”:882196,“name”:
Edit: nginx:n 429:ä tuli aika taajaan kahdessa vikassa erässä.
Joo, paljon tarttui POLLia, POSTia ja Nginx 429 tokan erän tykityksessä. Jännästi omalla kännykällä keskustelu rullasi kuitenkin pääpiirteittäin tosi hyvin - kävin kaksi kertaa etusivun kautta ja toinen niistä oli turha.
Mielenkiintoista on myös yleisön käyttäytyminen, joka nyt tyhjällä hallilla varmasti korostuu. Toisen erän SaiPan kavennus aiheutti taas hirmuisen kävijävyöryn (~360 isoimmillaan), joka sitten kuitenkin tasoittui taas 150 tasoille ja lopulta allekin.
Itteeni on alkanut tekniikkaa enemmän kiinnostaa miksi tälle palstalle pöllähtää satapäin jengiä kun vastustaja tekee maalin. Ja onko ne rekisteröityneitä käyttäjiä vai turisteja. Ja jos joku noista on rekisteröitynyt käyttäjä niin kertoisi motiivin tuolle toiminnalle.
Tuohon kysymykseen en osaa vastata muiden puolesta. Mutta kerronpa oman käytöstapani noissa live seuranta ketjuissa. Ennen peliä luen sitä. Mutta kun kiekko tippuu jäähän suljen puhelimen. Ja luen ketjua vain erä tauoilla ja pelin jälkeen. Nytkin Saipa maali tuli juuri erän lopussa. En tullut palstalle Saipan maalin takia vaan siksi että oli erä tauko. Heti kun erä tauko loppui poistuin taas palstalta. Minulla ei vaan riitä kyky seurata yhtä aikaa peliä ja kirjoitella palstalle. Ehkä tänään oli muitakin jotka kävivät vain erätauolla lukemassa seuranta ketjun.