Jep sinne vaan DISCOURSE_MAX_REQS_PER_IP_MODE: none asetuksen alle containers/app.yml:ään.
Itseäni Discoursen konfigurointi hieman hämäsi, kun Containerin sisällä tehdyt muutokset discourse.confiin jyrääntyy rebuildissa (vaikka koodin kommentista saa päinvastaisen kuvan) Mutta kehittäjät näyttävät aina viittaavan app.yml:n “env:” lohkoon, joten sinne vaan.
@ozzi Itselläkään ei ole esittää kuin pelkkä arvaus mitä arvoa DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS:ssa voisi koittaa, mutta jos tuon nyt tuplaa/triplaa alkuun niin ehkä siitä voi lähteä liikkeelle.
Jos tuo asetus ja sen arvo 0.2 ei sekään auta, niin sitten oikeastaan voisi jo siirtyä pomo-osastolle ja vetää hihasta profilointiasetuksen käyttöön niin näkee tarkalleen että kuinka kauan aikaa kuluu messagebusissa mihinkin operaatioon
No nyt saatiin sentään parannusta tilanteeseen, vaikka putkeen tämä ei mene vieläkään.
Muutama jumitus raportoitiin.
Joku näky ilmoituksen korkeasta kuormasta ja joutui guest-moodiin.
CPU:ta saatiin nyt enemmän kuormitettua ja korkein mitä näin oli 50% päälle. Se ei kuitenkaan selitä miksi jollekin oli tullut korkean kuorman guest mode.
Ei taida auttaa muu kuin laittaa profilointi päälle:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Tuleepahan sitten inspectoriin lisäheadereita näkyviin ja pääsee jyvälle millaisia suoritusaikoja menee jonossa, tietokannassa jne.
Itse en ollut päätteellä pelin aikana, mutta inspector oli auki ja muutama 429 siellä vieläkin oli. Viimeisin asetusmuutos saattoi olla suunta oikeaan päin, ehkä sitä voisi varovasti vielä nostaa esim. 0.3 een. Mutta profiloinnin se tosiaan käytännössä vaatii kylkeen.
Tässä on muuten sitten yksi out of the box -idea jos ette löydä syytä mistään ilmeisimmistä jutuista.
Mitä jos itse seurannassa ei olekaan mitään vikaa, vaan editointitoiminto bugaa ja aiheuttaa liikaa kyselyitä tai muuten jumittaa seurannan kaikilla. Eli kun viestejä tykitetään esim. maalin takia nopsaan ja en olekaan palstan ainoa nakkisormi niin viestien editointi aiheuttaisikin tuon ongelman.
Olitkos Android Chromen käyttäjä? Siinä on ihan omat jumi buginsa, jotka on tunnistettu jo kauannsitten mutta eivät vieläkään ole täysin kunnossa, useamman päivityksen jälkeenkään.
Anyway, Discourse kehittäjät ovat tunnistaneet ongelman ja korjauskin on jo kehitysversiossa. Otamme sen käyttöön sopivassa välissä, jahka valmistelevat työt on saatu tehdyksi.
This adds support for DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS
when set to true this will turn on performance related headers
X-Redis-Calls: 10 # number of redis calls
X-Redis-Time: 1.02 # redis time in seconds
X-Sql-Commands: 102 # number of SQL commands
X-Sql-Time: 1.02 # duration in SQL in seconds
X-Queue-Time: 1.01 # time the request sat in queue (depends on NGINX)
Tuossa ei paljastu mitään varsinaista “salasanatason tietoa” palvelimesta, joten siinä mielessä ei pitäisi olla estettä tuon käytölle sellaisenaan.
Betassa oleva Discoursen fix nähdäkseni parantaa tilannetta miten client käsittelee 429 vastauksia, mutta se juurisyy miksi 429:jä ylipäätään tulee olisi kutkuttava saada selville. Jos juurisyy on DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS niin sitten tällaisen profiloinnin kautta saisi enemmän lihaa arvausten ympäsille mihin asti asetusta voi/kannattaa nostaa.
Isoa vaikutusta ei kehittäjän mukaan pitäisi olla:
Building on all the micro benchmarks we can design a generic class for profiling methods quite efficiently in Ruby with very minimal runtime impact.
Oma oletus on että mitään huomattavaa vaikutusta ei tuosta synny, mutta ei näitä tietysti ikinä satavarmasti pysty sanomaan. Tyypillistä kaiken ohjelmistokehityksen kanssa
En nyt laittanut vielä @spartak:in ehdotusta päälle, koska mielestäni on hyvä tehdä ensimmäinen koeajo “puhtaalla” tuotantoversiolla
Torstaina on seuraava peli, jolloin nähdään pureeko Samin fixi. Jos homma taas sakkaa, niin jotain hackeja on mahdollista laittaa sisään ennen perjantain paikallista.
Työelämässä olisi ohjeistettu tyhjentämään välimuistia ehkä seitsemääntoista kertaan.
KUN (ei siis jos) joku ei toimi niin ainoa ohje on ollut aina se perrrkeleen välimuistin tyhjentäminen. Täällä on asiat huomattavasti paremmin vaikka asioita hoidetaan harrastepohjalta.
Chromella ei tökkinyt kahdessa vikassa erässä. Ekana tulee mieleen, että Chrome pääsi tekeen cachea betan kamoilla tyhjistä kun Bravessa mulla on vanhan palstan tavarat välimuistissa. Täytyy tyhjätä Braven cache ennen huomista matsia ja katsoa toimiiko.
Braven content filtteri voi myös sotkea asioita. Jos tekee Metaan bugiraporttia Bravella, niin hylkyyn menee.
Illan testisessio oli jotenkin “omituinen”. Käytös on selvästi muuttunut alkuperäisestä, mutta sen verran saatiin jumituksia toistettua, ettei ongelma ole betalla korjaantunut.
Vika on tosiaan clientissa, koska jos käy etusivulla, niin siellä näkyy laskurissa lukemattomat viestit kyllä – eli menevät kantaan.
Mutta kehittäjät näyttävät aina viittaavan app.yml:n “env:” lohkoon, joten sinne vaan.
