Open dezhidki opened 3 years ago
In GitLab by @Smibu on Nov 20, 2020, 17:52
Status: Tämä etenee hyvin haaralla cache
. Alkurefaktorointi (tietyt globaalit muuttujat pois) tuntuisi olevan melko lähellä valmista. Testailen ensi viikolla vielä suorituskykyä, ettei se jostakin syystä vahingossa huonone.
In GitLab by @Smibu on Nov 26, 2020, 14:03
Nyt refaktorointihaara saattaisi olla valmis. Laitoin sen tuonne: https://timdevs02-5.it.jyu.fi/. Katselen siellä joitakin paikkoja, ettei mikään vahingossa ole hajonnut. Päivitin devs02:een äsken uusimman tuotannon.
In GitLab by @Smibu on Nov 26, 2020, 14:12
Tuolla on ainakin joku vika; valittaa että demonro
:a ei ole määritelty.
In GitLab by @vesal on Nov 26, 2020, 14:53
Tuolla on ainakin joku vika; valittaa että demonro:a ei ole määritelty.
Joo niimpä näyttää vaikka se ko dokussa selkeästi on. Mutta lyhennetyssä versuioss näkyy:
https://timdevs02-5.it.jyu.fi/view/users/vesal/koe/cache/lyhyt
Missä näkee tuon nopeuseron tuotannon koodiin?
In GitLab by @Smibu on Nov 26, 2020, 15:02
valittaa että
demonro
:a ei ole määritelty.
Syy taisi löytyä; ei tykkää, jos oletus-urlmakro on numeerinen. Korjaan.
Missä näkee tuon nopeuseron tuotannon koodiin?
No nyt ei näe suoraan mistään kun pitäisi laittaa master-haara takaisin, että saa vertailuja.
Mutta ennen kuin vaihdoin tämän haaran, niin kokeilin ohj1 latautumisaikaa ja siinä ei ainakaan mitään havaittavaa eroa ole. master-haaralla oli 3.5s keskimäärin ja sain tällä cache-haaralla samaa luokkaa, ehkä aavistuksen nopeammin. Kerran tuli alle 3s.
In GitLab by @vesal on Nov 26, 2020, 15:04
Mutta ennen kuin vaihdoin tämän haaran, niin kokeilin ohj1 latautumisaikaa ja siinä ei ainakaan mitään havaittavaa eroa ole. master-haaralla oli 3.5s keskimäärin ja sain tällä cache-haaralla samaa luokkaa, ehkä aavistuksen nopeammin. Kerran tuli alle 3s.
Siis onko tuotannossa tämä sama haara vai mitä tarkoitat?
In GitLab by @Smibu on Nov 26, 2020, 15:07
Siis onko tuotannossa tämä sama haara vai mitä tarkoitat?
Tuotannossa on tuotannon koodi. Tämä cachehaara on devs02-koneella.
Tarkoitan, että tuotanto- ja devs-koneethan eivät suoraan ole vertailukelpoisia, kun niissä on eri määrä prossuja jne. Eli jos haluaa vertailla tarkasti pelkästään koodien eroa, niin devs02-koneella pitäisi ensin masterin koodilla ottaa mittauksia joistakin dokumenteista, ja sen jälkeen vaihtaa tämä haara käyttöön, ja ottaa samat mittaukset uudelleen.
In GitLab by @Smibu on Nov 26, 2020, 15:26
Syy taisi löytyä; ei tykkää, jos oletus-urlmakro on numeerinen. Korjaan.
Tuo korjattu.
In GitLab by @Smibu on Nov 26, 2020, 15:41
Ainakin sellainen ero on, että nyt jos tavallisissa tekstikappaleissa käyttää urlmakroja, niin sellaisiin täytyy laittaa nocache=true. Muuten makron arvo ei päivity niihin, jos arvoa vaihtaa urlissa. Nähtävästi aiemmin tuo on vahingossa toiminut myös ilman nocachea.
In GitLab by @Smibu on Nov 26, 2020, 16:09
niin sellaisiin täytyy laittaa nocache=true
Teen tuolle pikaisen skriptin; noita urlmakroja esiintyy matikan ja tilaston dokuissa jonkin verran.
In GitLab by @vesal on Nov 26, 2020, 16:50
Tarkoitan, että tuotanto- ja devs-koneethan eivät suoraan ole vertailukelpoisia, kun niissä on eri määrä prossuja jne. Eli jos haluaa vertailla tarkasti pelkästään koodien eroa, niin devs02-koneella pitäisi ensin masterin koodilla ottaa mittauksia joistakin dokumenteista, ja sen jälkeen vaihtaa tämä haara käyttöön, ja ottaa samat mittaukset uudelleen.
No joo, mutta käsittääkseni tuotannon konekin laskee vain yhdellä prossulla yhtä dokumenttia. Eli jos joku doku on nyt devsissä nopeampi niin se on parantunut. Ja kai nuo prossut perustaltaan ovat sampja, eli aika likelle vertailukelpoisia. Eroa voi tulla siitä että toisessa on ykis virtuaalitaso enemmän.
In GitLab by @Smibu on Nov 27, 2020, 16:52
Teen tuolle pikaisen skriptin; noita urlmakroja esiintyy matikan ja tilaston dokuissa jonkin verran.
Tuo skripti ajettu. devs-koneella en havaitse refaktorointihaaralla enää vikoja. Pistän tuotantoon klo 18 maissa. Ei vaadi katkoa.
In GitLab by @Smibu on Nov 27, 2020, 17:58
Pistän tuotantoon klo 18 maissa. Ei vaadi katkoa.
Laitettu.
In GitLab by @Smibu on Nov 27, 2020, 18:00
Pistin devs02-5-koneelle varulta vanhan masterin, jos pitää verrata toimintaa.
In GitLab by @vesal on Nov 27, 2020, 18:04
Tuo skripti ajettu. devs-koneella en havaitse refaktorointihaaralla enää vikoja. Pistän tuotantoon klo 18 maissa. Ei vaadi katkoa.
Tuliko sitä nopeushyötyä mihin tilanteisiin?
In GitLab by @Smibu on Nov 27, 2020, 18:17
Tuliko sitä nopeushyötyä mihin tilanteisiin?
Nopeushyöty ei ollut tuon refaktoroinnin tavoite; ainoastaan niistä tietyistä g
-globaaleista eroon pääseminen. Siksi yritin tarkistella vain, ettei ainakaan tule mitään hidastumisia.
Nopeuden pitäisi olla siis samaa luokkaa kuin ennenkin, mutta voi olla aavistuksen parempikin, koska sain joitakin iffittelyjä poistettua. Myös nuo URL/rand-makrot lasketaan nyt järkevässä paikassa, toisin kuin ennen.
In GitLab by @vesal on Nov 27, 2020, 19:05
Nopeushyöty ei ollut tuon refaktoroinnin tavoite; ainoastaan niistä tietyistä g-globaaleista eroon pääseminen. Siksi yritin tarkistella vain, ettei ainakaan tule mitään hidastumisia.
Mutta eikös sulla ollut se idea että kun doku avataan ekan kerran, niin mitään ei tarvitse laskea vaan saadaan sillion doku nopeasti. Siis niitä tenttejä ja kokeita varten?
In GitLab by @Smibu on Nov 27, 2020, 19:17
Mutta eikös sulla ollut se idea että kun doku avataan ekan kerran, niin mitään ei tarvitse laskea vaan saadaan sillion doku nopeasti. Siis niitä tenttejä ja kokeita varten?
Joo. Tämä refaktorointi oli vain edellytys sille, että sen cachen muodostaminen hoituu luotettavammin. Ei tämä kortti vielä valmis ole.
In GitLab by @Smibu on Dec 1, 2020, 16:47
Tämä ei ehdi valmiiksi 3.12. kokeeseen mennessä. Siihen 14.12. kokeeseen mennessä uskoisin ehtivän.
In GitLab by @vesal on Dec 1, 2020, 16:53
Tämä ei ehdi valmiiksi 3.12. kokeeseen mennessä. Siihen 14.12. kokeeseen mennessä uskoisin ehtivän.
No sillä mennään sitten... Pistetään minuutin hajautus.
In GitLab by @vesal on Dec 2, 2020, 09:24
Tuokin pitää jotenkin toteuttaa siihen:
Eli kun on pakotettu pistejuttu näkymään vaikka ei ole vielä tehnyt mitään:
point_sum_rule:
breaklines: true
force: true
linktext: ">mene"
Mutta tuo on periaattessa vakio kaikille.
Tosin toinen kysymys on, että onko tämä edes järkevä näin, vai olisiko parempi olla angular-komponentti, jota voisi säätää dokumentissa paremmin eri paikoihin yms ja vaikuttaa myös sitten paremmin ulkosuun. Ja ehk ä vielä sijoitella osan likemmäksi itse tehtäviä ja tarjota myös automaattinen päivitys
In GitLab by @Smibu on Dec 2, 2020, 09:32
Tuokin pitää jotenkin toteuttaa siihen:
Sehän on vain html:ää, joka view-reitissä annetaan muiden muassa, eli eihän tuo vaikeuta suuntaan tai toiseen.
Tosin toinen kysymys on, että onko tämä edes järkevä näin, vai olisiko parempi olla angular-komponentti
Ilman muuta sen kannattaisi olla Angular-komponentti. Tuo task summary on hyvin vanhaa koodia alun perin ja siksi se on tuolla jinja-templatessa.
In GitLab by @Smibu on Dec 10, 2020, 20:03
Nyt on eka versio tästä cachesta valmis ja voi testailla vaikka tuossa:
https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
Cache on oletuksena pois käytöstä ja sen saa käyttöön asetuksella cache: true
, kuten tuonne dokuun laitoin.
Nykyiset tunnetut puutteet/TODOt ainakin: (siirretty korttiin)
In GitLab by @vesal on Dec 11, 2020, 07:18
oonkos mää nyt edes ensikertalainen lukija? pitääkö olla joku muu tunnus?
In GitLab by @vesal on Dec 11, 2020, 07:18
Tuossa:
https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/2020s/tentti/20201203
tuntuu palvelimen aika tippuvan 2.3 sek => 0.4 sek. Eli onhan se huomattava parannus ja auttaa varmaan jos on satoja käyttäjiä.
Kokeilitko sillä ./stresstest.sh vai mikä se oli? Eli mihin määriin sillä pääsee.
Mutta ihmeellisesti tuossa em dokussa get_annotations vie 11 sek. Eikä käyttäjälla edes ole niitä?
In GitLab by @vesal on Dec 11, 2020, 07:18
En tiedä olisiko noihin luottoa:
charra:~>cd tim charra:~/tim>./stresstest.sh 256 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m0.675s user 0m0.096s sys 0m0.116s Errors: 0
charra:~/tim>./stresstest.sh 1024 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m2.564s user 0m0.347s sys 0m0.473s Errors: 0
In GitLab by @vesal on Dec 11, 2020, 07:18
Ei nuo stresstestit ollu oikeita :-( wget ei toimi oikein mistään:
[vesal@timdevs02 tim]$ wget https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1 --2020-12-10 23:17:46-- https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1 Resolving timdevs02-5.it.jyu.fi (timdevs02-5.it.jyu.fi)... 130.234.173.12 Connecting to timdevs02-5.it.jyu.fi (timdevs02-5.it.jyu.fi)|130.234.173.12|:443... ^C
In GitLab by @vesal on Dec 11, 2020, 08:58
Mikseihän tuo rinnkkaisttu yhtään:
charra:~/tim>./stresstest.sh 1 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m0.418s user 0m0.040s sys 0m0.023s Errors: 0
charra:~/tim>./stresstest.sh 2 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m0.510s user 0m0.093s sys 0m0.055s Errors: 0
charra:~/tim>./stresstest.sh 4 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m0.726s user 0m0.187s sys 0m0.110s Errors: 0
charra:~/tim>./stresstest.sh 8 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m1.185s user 0m0.390s sys 0m0.206s Errors: 0
charra:~/tim>./stresstest.sh 16 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m2.073s user 0m0.764s sys 0m0.428s Errors: 0
charra:~/tim>./stresstest.sh 32 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m3.465s user 0m1.543s sys 0m0.797s Errors: 0
charra:~/tim>./stresstest.sh 64 https://timdevs02-5.it.jyu.fi/view/kurssit/tie/ohj1/moniste/Ohjelmointi-1
real 0m6.532s user 0m3.108s sys 0m1.474s Errors: 0
In GitLab by @Smibu on Dec 11, 2020, 09:54
En kokeillut stress-skriptiä vielä.
Mutta ihmeellisesti tuossa em dokussa get_annotations vie 11 sek. Eikä käyttäjälla edes ole niitä?
Loin https://gitlab.com/tim-jyu/tim/-/issues/2107
oonkos mää nyt edes ensikertalainen lukija? pitääkö olla joku muu tunnus?
Cache on tunnuskohtainen, eli ensimmäinen lataus ei ole cachessa. Eli tätä varten teen sen cachen esigeneroimisnapin, niin koesivuille saa nopean latauksen.
In GitLab by @vesal on Dec 11, 2020, 09:57
Cache on tunnuskohtainen, eli ensimmäinen lataus ei ole cachessa. Eli tätä varten teen sen cachen esigeneroimisnapin, niin koesivuille saa nopean latauksen.
Paljonokos tuo sitten vie tilaa jos on vaikka se 6000 hakijaa? Ja tuo generointi aikaa? Voisko erottaa paljonko jää oikeasti henkilökohtaista vaikka jotenkin että tekee parille käyttäjälle, ottaa diifin ja sitten sitä diffin eroa generoi kaikille käyttäjille?
In GitLab by @Smibu on Dec 14, 2020, 10:32
marked the task Kun lisätään kommentti. as completed
In GitLab by @Smibu on Dec 14, 2020, 13:43
marked the task nocache=true ei tyhjennä cachea as completed
In GitLab by @Smibu on Dec 14, 2020, 19:19
Pistin nyt tähänastisen version cachesta tuotantoon.
In GitLab by @Smibu on Jan 18, 2021, 11:02
marked the task Sivupalkkiin painike, joka generoi cachen käyttäjäryhmälle (kokeita varten). as completed
In GitLab by @Smibu on Jun 30, 2021, 18:09
unassigned @Smibu
In GitLab by @Smibu on Nov 12, 2020, 14:56
Tavoite on saada dokumentti palvelimella välimuistiin niin, että se annetaan selaimelle view-reitissä välittömästi. Olkoon tämän nimitys "pikacache".
Käyttötapaus erityisesti tentit, joiden alussa moni aukaisee dokumentin yhtäaikaa. Ilman pikacachea TIM joutuu koville (riippuen toki dokumentin koosta ja pluginien määrästä).
Dokumentissa voi olla käyttäjästä riippuvia asioita, kuten käyttäjämakroja, satunnaistusta ja/tai vastattuja tehtäviä, joten välimuistin pitää olla käyttäjäkohtainen. Mahdollisesti dokumentin asetuksella voisi Timille "vakuuttaa", että dokumentti on kaikille samanlainen eli siinä ei ole mitään käyttäjäkohtaista. Tämä olisi sitten dokumentin muokkaajan vastuulla ja jos se ei pidäkään paikkaansa, niin seurauksena dokumentti vuotaisi satunnaisen käyttäjän tietoja muille käyttäjille.
Itse asiassa lukumerkinnäthän ovat aina käyttäjäkohtaisia, joten tuo "kaikille sama pikacache" voi olla ongelmallinen. Lukumerkinnät pitäisi noutaa erikseen JavaScriptillä.
Milloin pikacacheen lisätään tavaraa
Milloin pikacache täytyy tyhjentää
Nykyiset tunnetut puutteet/TODOt ainakin: