Suorituskyky #926

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on Sep 13, 2014, 15:43

Tähän korttiin voi liittää kaikki suorituskykyyn liittyvät kortit.

Checklist

Vesa Lappalainen

In GitLab by @Smibu on Sep 13, 2014, 20:59

Sitten yksi tosi kiusallinen on että tuon uploadin jälkeen dokumentti 1 kestää nyt yli minuutin ladata. Tuntuu että tuo aika kasvaa koko ajan ja sitten on tylsää editoida tuota dokua millään tavalla kun uusi katsomine kestää aina kauemmin ja kauemmin.@mikkalle – Vesa Lappalainen

In GitLab by @Smibu on Sep 15, 2014, 08:39

@mikkalleTuo block-taulu rupeaa pelottamaan erityisesti tuon tyypin 5 suhteen, sillä jos monisteella on 1000 lukijaa ja jokainen on lukenut koko monisteen, niin tuonne tulee 1000 monistetta. Ja jos monisteita on joskus kymmeniä/satoja, niin silloin tietokanta ei mahdu enää muistiin ja sen teho laskee merkittävästi.

Vähintään nuo tekstilohkot kannattaisi tallettaa jonnekin toiseen tauluun (yhteen kertaan/ samanlainen lohko, voiko tiiviste olla hakuavaimena) ja sen kaverina autoindex, jolla noihin viitataan block-taulusta. Sitten tuosta block taulusta ei mielestäni(???) ole viitettä siihen dokuun, johon viitataan? – Vesa Lappalainen

In GitLab by @Smibu on Sep 15, 2014, 09:10

Uploadissa kestää todennäköisesti se, että nyt kun lukumerkintöjä on paljon, niin jokaisen dokumentin muokkauksen yhteydessä niiden paikat lasketaan uudelleen (mätsäysalgoritmilla) ja vielä niin, että jokaisesta lukumerkinnästä menee oma HTTP-pyyntönsä Ephemeralille. Tämä ei ollut tietysti alussa ongelma, kun merkintöjä ei juuri ollut. Pitäisi olla helppo korjata, koska on olemassa toinen funktio, joka mätsää kaikki kappaleet kerralla.

Monisteen kokonaiskäynnistymisajasta en suoraan osaa sanoa, mikä siinä voisi olla. Voisin sitä koittaa profiloida, että mikä siinä kestää.

In GitLab by @Smibu on Sep 15, 2014, 09:22

Tää uudelleenlaskenta on juuri se, johon toivoin ettei ikinä jouduttaisi. Sen näkee heti, että tuo tulee olemaan pullonkaula :-( Ja sekö sama on nyt ongelmana jos editillä muuttaa yhtä kappaletta? – Vesa Lappalainen

In GitLab by @Smibu on Sep 15, 2014, 09:31

Joo toistaiseksi tuota samaa mätsäysfunktiota kutsutaan minkä tahansa muokkauksen yhteydessä.

Yksittäisen kappaleen muokkaamista on varaa optimoida runsaastikin, koska tiedetään esim., että sitä ennen olevat eivät muuttuneet ollenkaan, ja jos kappaleita ei tullut lisää (eikä poistunut), niin ei tarvitsisi tehdä mitään.

In GitLab by @Smibu on Sep 15, 2014, 18:35

Monisteen käynnistymisen hidastuminen johtuu siitä, kun refaktoroin pluginkäsittelykoodia varmemmaksi. Eli nyt tuo tarkistus, että sisältääkö kappale pluginin, tehdään HTML-parserilla. Eli katsotaan, onko HTML muotoa

<pre id="k1" plugin="showImage"><code>width: 600
height: 150
file: /images/24/dsc_0014.jpg</code></pre>

Aiemmin tuossa oli pelkkä merkkijonotarkistus, että sisältyykö tuohon <pre ja plugin=" ja <code>. Se oli nopea, mutta epävarmempi. Kokeilin toista HTML-parseria, ja se oli selvästi nopeampi (parannus 5.4 s -> 1.1 s). Merkkijonotarkistus olisi taatusti sitäkin nopeampi.

Varma ja samalla nopea tapa lienee sellainen, että ensin katsoo, alkaako blokki merkeillä <pre ja jos ei, niin silloin kappale ei varmasti ole plugin. Jos alkaa, niin vasta sitten aletaan parsimaan HTML:ää.

Kännyköillä pullonkaula lienee JS:n suorittaminen? Nuo ajat ovat tosiaan sellaisia, ettei kukaan jaksa latautumista odotella. Angularin päivitys saattaa auttaa, mutten osaa sanoa, kuinka paljon.

In GitLab by @Smibu on Sep 15, 2014, 21:58

@tomijkarppinen @Smibu Minkäs taki pluginissa alku olisi

?? Vai tekeekö pandoc sen, että se tekee plugineista pre vaikka ne eivät pre tuottaisikaan? Eikä tuon "<pre.plugin.>" saa ihan regexpillä (ei-ahneella versiolla että ottaa ekan >). Ja vasta sitten käyttää jotakin muuta. Noita pre tulee ohj monisteessa melkoisesti ja turha kai niitä on katsoa jos eivät ole plugin.

Mutta toisaan tuo tilnakulutuskin mua rupeaa huolestuttamaan. – Vesa Lappalainen

In GitLab by @Smibu on Sep 15, 2014, 22:13

Angularin vaihto ei vaikuttunut Lumia 820 Ohj1-monisten hakuaikaan. – Vesa Lappalainen

In GitLab by @Smibu on Sep 16, 2014, 10:45

Vai tekeekö pandoc sen, että se tekee plugineista pre vaikka ne eivät pre tuottaisikaan?

Joo, Pandoc kun muuntaa markdownin HTML:ksi, niin pluginblokit ovat tuonnäköisiä.

Eikä tuon "" saa ihan regexpillä (ei-ahneella versiolla että ottaa ekan >). Ja vasta sitten käyttää jotakin muuta.

Joo tuo on varmastikin ihan toimiva tapa.

Mutta toisaan tuo tilnakulutuskin mua rupeaa huolestuttamaan.

Tilankulutus ratkennee helpoiten tallettamalla tekstikappaleen tiiviste eikä itse tekstiä. Esim. CRC-32 riittänee hyvin. Siinä jää hyvin pieni mahdollisuus sille, että kappaleen muutoksen jälkeen tuo CRC-arvo onkin sama, jolloin kappale pysyy tilassa "luettu". Tuota voisi parantaa käyttämällä pidempää tiivistettä (esim. SHA-1), joka veisi hieman enemmän tilaa.

In GitLab by @Smibu on Sep 16, 2014, 11:06

@Smibu Minusta EI SAA tallentaa tekstin sisältöä, koska se monistuu kaikille samana. Minusta pitäisi tallentaa viite: moniste-versio-kpl numero (joka on oikeastaan sama kui mitä aikanaan yritin sanoa, eli jokaisella kappaleella on 1-käsitteinen tunnus).

Sitten panostetaan palikkaa, joka vastaa ERITTÄIN nopeatsi kysymykseen:

Mikä on nykyisen monisteen vastine viitteelle: moniste - versio - kpl.nro

Tätä varten kaikkien eri monisteiden eri versioiden kappaleet ovat tietokannassa josta voidaan kuleka tuo ketju läpi ja heti kun se on kuljettu jollekin kolmikolle, niin sen kohdalle saadaan suoraan vastaus jota voidaan käyttää kun seuraava tekee tämän kysymyksen. Tämä siksi, että meille on lopputuotteesta vain yksiversio ja kysymys on aina kiinostunut vain viimeisimmän monisteen vastaavista arvoista.

Taulun sisältö on siis yhden rivin osalta karkeasti:

Olkoon uusin moniste mu,vu Nyt kun teen jollekin kysmyksen kolmikolle m,v,k niin sille löytyy tuolta VAIN yksi rivi. Mutta rivillä oleva moniste,versio -pari ei ole mu,vu. Silloin rekursiivisesti sovelletaan samaa kysymystä kunnes tulee mu,vu TAI ko ei löydy (silloin kpl on poistettu)

Tämä tieto laitetaan alkuperäiselle riville ennenkuin tulos palautetaan. jos kanta on oikein indeksoitu, niin vastaus kysymykseen SUURIMASSA osassa tapauksia löytyy O(1) ajassa.

Pitäisikö tästä pitää palaveri joskus? – Vesa Lappalainen

In GitLab by @Smibu on Sep 16, 2014, 13:13

Minusta EI SAA tallentaa tekstin sisältöä, koska se monistuu kaikille samana.

Juu, tästä oon toki samaa mieltä :)

Tuo ehdotuksesi lienee toimiva, mutta en osaa ihan heti sanoa, olisiko se parempi kuin mitä itse olen ajatellut. Eli omassa mallissani olisi taulu tyyliin

user_id | doc_id | kpl_index | kpl_hash
      1 |      1 |         5 | 6876abf4
      1 |      1 |         7 | 10a76ffe

jossa käyttäjällä 1 olisi luettuna kappaleet 5 ja 7 dokumentista 1. Tuo kpl_hash on laskettu kappaleen sisällöstä silloin, kun lukumerkintä on tehty. Nyt jos käyttäjä 1 avaa dokumentin 1, niin käydään hakemassa taulusta lukumerkinnät ja lasketaan dokumentin tekstikappaleista 5 ja 7 tiivisteet. (Nämä tiivisteet voisi laskea valmiiksi välimuistiin aina kun dokumenttia muokataan, ettei niitä tarvitse joka kerta laskea, kun dokumenttia avaa.) Jos lasketut tiivisteet ovat samat kuin taulussa olevat, niin kappaleet ovat tilassa "luettu". Jos ne eroavat, niin kappaleita on muokattu lukemisen jälkeen.

Tuo kpl_hash voinee olla 32-bittinen luku, eli siihen mahtuu CRC-32. Jää siis hyvin pieni mahdollisuus sille, että kappaleen muokkauksen jälkeen kpl_hash on sama kuin ennen muokkausta, mutta tämän ei pitäisi olla käytännössä mikään ongelma.

Jos dokumenttia muokataan olennaisesti (esim. alkuun lisätään 1 uusi kappale), niin tietokannassa olevia indeksejä päivitetään, eli ne vastaavat aina uusinta versiota dokumentista. Tiiviste päivitetään tietokantaan vain silloin, kun käyttäjä painaa "olen lukenut".

Kappaleiden sisältöjä ei siis missään vaiheessa tallennettaisi tietokantaan (koska ne ovat jo gitissä/välimuistissa ja siksi se tuntuu vähän turhalta monistamiselta).

Voin tulla huomenna TIM-huoneeseen klo 14:30, jos tarvii palaveerata. @vesal

In GitLab by @Smibu on Sep 16, 2014, 17:44

@Smibu Tuossa on ilman versionumeroa se ongelma, että tuo kpl_index ei pidä paikkaansa. Ja sitä ei ole järkevä käydä päivittämässä tuhansiin paikkoihin joka kerto kun tektsi muuttuu. Jos oikein oymmärsin, niin nykyinn hitaus johtuu juuri pitkälle siitä, että joka muutoksella päivitetään hirveä määrä tavaraa. Kappaleen sisältöä ei tarvitse tarllettaa, jos joku vastaa nopeasti kysymykseen anna_kappale(doc,ver,idx).

SUURIN osa dokumneitn muutoksia on sellaisia, että nuo indeksit muuttuvat, siksi ei saa olla niiden uudelleen laskentaa. Se korvataan sillä, että on nopea funktio

anna_nyky_dokun_index(doc.ver,idx)

Hash voi olla siellä "välitaulussa" jossa kerrotaan miten nuo ovat "mäppäytyneet" (koska siellä se on yksikäsitteinen ja säilyy samana varmasti).

Historian kannaltta olisi hyvä (vaikka menisi eri tauluunkin), tietää miten käyttäjät ovat noita merkintöjä antaneet.

Eli tuossa merkintätaulussa

    user_id | doc_id | ver |kpl_index | timestamp
          1 |      1 | 123 |        5 |  15.9.2014 7:23
          1 |      1 | 123 |        7 |  15.9.2014 7:25

voi vaihtaa ver-numeroa ja kpl numeroa silloin kun ne on tämän userin kohdalla HAETTAESSA jouduttu uudelleen laskemaan. Mutta samalla tuo vanha rivi kannattaa tallettaa. Se että onko tuo muuttunut vai ei, näkyy siitä, että löytyykö tuolle (1,123,5) tuosta toisesta taulusta minkälainen edittype

  doc_id | ver |kpl_index | kpl_hash | new_ver | new_index | edittype
       1 | 123 |        5 | 6876abf4 | 124     | 5         | none
       1 | 123 |        7 | 6876abf8 | 124     | 8         | move+edit
       1 | 124 |        5 | 6876abf4 |         |           |
       1 | 124 |        8 | 6076cbf3 |         |           |

minkälainen edit-tieto.

Eli tässä toisesa taulussa on editointihistoria ja kappaleiden liikeet.

Jos kysytään id= anna_nyky_dokun_index(1.123,5)
nin vastaus on 5 koska riviltä 1 löytyy jo tieto että siirtoketjun pää on 124 (nykydokun numero). Koska hash on sama kuin nykydokulla, ei ole muutosta. Tuo taulu siis elää sillon kun hakuja tehdään. Eli nyt jos jollain on viite (1,124,8) ja joku tekee muutoksen kappaleeseen 8, niin taulu muuttuisi:

  doc_id | ver |kpl_index | kpl_hash | new_ver | new_index | edittype
       1 | 123 |        5 | 6876abf4 | 124     | 5         | none
       1 | 123 |        7 | 6876abf8 | 124     | 8         | move+edit
       1 | 124 |        5 | 6876abf4 |         |           |
       1 | 124 |        8 | 6076cbf3 | 125     | 8         | edit
       1 | 125 |        8 | 6076cbaa |         |           |

eli tulee yksi rivi lisää tästä muuttuneesta kappaleesta ja tieto mikä on sen vastin uusimmassa dokussa (en ole varma tarviiko niistä tallettaa mitään, jota eivät ole liikkuneet/muuttuneet??).
Tehdään vielä toinen muutos kappaleeseen 8:

  doc_id | ver |kpl_index | kpl_hash | new_ver | new_index | edittype
       1 | 123 |        5 | 6876abf4 | 124     | 5         | none
       1 | 123 |        7 | 6876abf8 | 124     | 8         | move+edit
       1 | 124 |        5 | 6876abf4 |         |           |
       1 | 124 |        8 | 6076cbf3 | 125     | 8         | edit
       1 | 125 |        8 | 6076cbaa | 126     | 8         | edit
       1 | 126 |        8 | 6076cbee |         |           |

Sitten kun käyttäjälle pyydetään tietoa tuolla id= anna_nyky_dokun_index(1,124,8)

niin riviltä 4 löytyy tuo tieto (125,8) ja kun etsitään (125,8) löytyy 126,8 ja tämä vaihdetaan rivin 4 tiedoksi, jotta seuraavalla haulla tuo tieto saadaan suoraan.

Tällä tavalla käyttäjäkohtaisia tietoja ei tarvitse muuttaa ennekuin käyttäjä uudelleen klikkaa ko kappaletta. Ja jos jollakin toisella on ollut sama viite, niin mitään ei tarvitse laskea uudelleen.

Toki kysymykseen: kenellä on viite kohtaan (1,126,5) ei ole nopea vastata. – Vesa Lappalainen

In GitLab by @Smibu on Sep 17, 2014, 21:41

Tässä on nyt (alustava) testausskripti tuolle mäppäystaululle. Se tekee nuo asiat:

Luo taulun par_mapping ja sille indeksin par_index tietokantaan
Lisää 500 kertaa 2000 riviä tauluun (sisältäen jonkinlaista järkevähköä testidataa)
Commitoi ne levylle
Lisää kerran 2000 riviä tauluun ja commitoi ne
Hakee yhdellä kyselyllä tietyn dokumentin tietyn version kaikkien kappaleiden mäppäykset
Hakee yksi kerrallaan tietyn dokumentin tietyn versio tietyn kappaleen mäppäyksen

Profiloin skriptin omalla koneellani komennolla

python -m cProfile -s cumtime sqlite_test.py > res.txt

ja tuli tuommoiset tulokset (vain ylimmät, merkitykselliset rivit mukana):

       1012403 function calls (1012376 primitive calls) in 54.535 seconds

 Ordered by: cumulative time

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    4/1    0.000    0.000   54.535   54.535 {built-in method exec}
      1    0.008    0.008   54.535   54.535 sqlite_test.py:1(<module>)
    501    1.795    0.004   51.012    0.102 sqlite_test.py:5(insert_many)
1004003   49.346    0.000   49.346    0.000 {method 'execute' of 'sqlite3.Cursor' objects}
      2    2.698    1.349    2.698    1.349 {method 'commit' of 'sqlite3.Connection' objects}
      1    0.000    0.000    1.951    1.951 sqlite_test.py:13(insert_many_with_commit)
   2001    0.661    0.000    0.661    0.000 {method 'fetchall' of 'sqlite3.Cursor' objects}
      1    0.000    0.000    0.649    0.649 sqlite_test.py:18(find_rows)
   2000    0.005    0.000    0.143    0.000 sqlite_test.py:28(find_one_row)

Tietokannan koko skriptin ajamisen jälkeen on 57 373 KB (taulussa on siis miljoona riviä). Tuossa tallennetaan dokumentista juokseva versionumero. Hashilla koko tulisi reilusti suuremmaksi.

Eli hakeminen lienee riittävän nopeaa. 2000 rivin lisääminen tauluun (insert_many_with_commit) silloin, kun taulussa on jo paljon tavaraa, vie n. 2 sekuntia.

Tuota voisi testailla tim-beta-koneessakin, että onko miten paljon eroa.

In GitLab by @Smibu on Sep 17, 2014, 22:12

@Smibu @tomijkarppinen Entä arvaus sellaiselle, missä nuo 2000 riviä ovat jo tuolla taulussa ja sitten jokaiseen on se viite ja kun lisätään kapple dokumentin alkuun, pitää kaiklle tehdä se uusi kolmikko (doc,ver,knro) sinne rivin loppuun. Eli 2000 rivin update.

Vaikuttaisiko hashin käyttö nopeuteen? Kokoonhan se ei sillä tavalla vaikuta, että jos versiomuutokset numeroitaisiin juoksevasti, niin ne hashit pitäisi tallettaa toiseen tauluun. Taikka joo, onhan silloin toki yhteen versionumeron (hash) monia viittauksia, eli kyllä se taitaisi kokonaissaldoa pienentää. Tuon pieni lisähinta olisi sitten se, että tietoa ei voi laskea uudestaan jos tuo versiohash-juokseva versionumero taulu hukkuisi/hajoaisi. – Vesa Lappalainen

In GitLab by @Smibu on Sep 17, 2014, 22:15

sehän taisi olla niin, että rivejä ei tarvinnutkaan lisätä (???) ennenkuin joku viittaa. Eli se suurin pumpsi tuli silloin kun kappale lisätään/poistetaan ja kaikkien entisten lehtisolmujen tilalle (jotka ovat taulussa, kaikkihan eivät välttämättä ole) piti laittaa se uusi "kolmikko".

Paljonkos tuossa olisi se hakuaika, en ihan saanuit selväksi? – Vesa Lappalainen

In GitLab by @Smibu on Sep 18, 2014, 16:33

Vastaavat tulokset tim-beta-koneeella containerin sisällä ajettuna

1011529 function calls in 22.878 seconds


 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      1    0.007    0.007   22.878   22.878 sqlite_test.py:1(<module>)
    501    0.866    0.002   22.334    0.045 sqlite_test.py:5(insert_many)
1004003   21.534    0.000   21.534    0.000 {method 'execute' of 'sqlite3.Cursor' objects}
   2001    0.394    0.000    0.394    0.000 {method 'fetchall' of 'sqlite3.Cursor' objects}
      1    0.000    0.000    0.384    0.384 sqlite_test.py:18(find_rows)
      1    0.000    0.000    0.151    0.151 sqlite_test.py:13(insert_many_with_commit)
   2000    0.004    0.000    0.080    0.000 sqlite_test.py:28(find_one_row)
      2    0.061    0.031    0.061    0.031 {method 'commit' of 'sqlite3.Connection' objects}
    503    0.005    0.000    0.005    0.000 {range}
   2503    0.004    0.000    0.004    0.000 {method 'cursor' of 'sqlite3.Connection' objects}
``` – *Tomi Karppinen*

In GitLab by @Smibu on Sep 18, 2014, 18:56

@tomijkarppinen @Smibu Tuota testiähän pitää hieman muutta, koska se hakee niin säännöllistä tavaraa että voi helposti antaa optimistisia tuloksia.

Jos sitä oppilaanm erkintöjä haluaa simuloida, niin pitää ensin hakea blocks taulusta oppilaan kaikki tähän dokuun liittyvät merkinnät (yksi SQL-haku), voi tuottaa esim. 2000 kolmikkoa (doc,ver,knro). Tuossa doc on tarpeeton koska sen on koko ajan sama. Sitten näitä vastaavia nykyisen doc,ver,krno tietoja lähdetään hakemaan tuosta taulusta ja tätä en tiedä voiko tehdä muuta kuin silmukalla. Sitä varten kannattaa prepared kysely valmiiksi ja sitten silmukassa vaihdetaan parametriä. – Vesa Lappalainen

In GitLab by @Smibu on Sep 18, 2014, 21:10

@vesal @tomijkarppinen Laitoin tähän kortin kuvaukseen vähän sitä, että mitä ollaan tässä pari viime päivää suunniteltu. Voi tosiaan kommentoida tuohon tekstin sekaan, jos se tuntuu luontevammalta.

In GitLab by @Smibu on Sep 21, 2014, 21:56

@Smibu @tomijkarppinen Nyt on moniste 1 mennyt siihen kuntoon, että en voi enää lainkaan editoida sitä. TIM menee toimintakyvyttömäksi kymmeniksi minuuteiksi editoinnista. Nähtävästi viittausten määrä on kasvanut niin isoksi. Eli nyt tälle on pakko ruveta tekemään jotakin... – Vesa Lappalainen

In GitLab by @Smibu on Sep 22, 2014, 10:19

@vesal Joo monisteessa näyttää olevan reilu 14000 lukumerkintää/kommenttia. Voin tänään tehdä sellaisen "välioptimoinnin", että nuo kappaleiden mäppäykset kysytään välimuistista vain kerran per muokkaus. Nyt siellä on tosiaan silmukka, jossa mäppäykset kysytään yksitellen jokaisen merkinnän kohdalla, ja siinä ei ole järkeä. Se on varmasti suurin pullonkaula. Nuo rivin päivitykset tietokantaan pitäisi olla suht nopeita. Tosin sitäkin voisi nopeuttaa luomalla indeksin tuon tietyn sarakkeen suhteen; tätäkin kannattanee kokeilla.

Tämä on helppo muutos, mutta testaan ensin lokaalisti ja betalla, että tuo varmasti toimii. On muistaakseni kerran aiemmin testattu, mutta nyt on hyvä olla varma.

In GitLab by @Smibu on Sep 22, 2014, 11:41

@Smibu Saatko tuosta TIMin kannan versiosta kopioi betaan, niin voi samalla datamassalla kokeilla vaikutusta. Isoin ongelma on siis 10 min refresh aika jokaisen muutoksen jälkeen. – Vesa Lappalainen

In GitLab by @Smibu on Sep 22, 2014, 15:18

@vesal Joo kyllähän sen sinne saa, mutta lokaalistikin kokeilemalla sai ihan hyvän käsityksen parannuksesta.

Eli jos dokumentin 2000 kappaleessa on jokaisessa muistiinpano, niin mäppäyksen haku vie nykyversiolla (lokaalisti kokeiltuna) n. 40 sekuntia. Tuon kun muutti niin, että haetaan mäppäys kerralla, niin se vie enää n. 6 sekuntia. Ja tämä aika ei siis kasva muistiinpanojen lisääntyessä, vaan vain, jos dokumentin kappalemäärä kasvaa.

Toinen mikä nykyversiossa on epäoptimaalista on tuon mäppäyksen päivitys tietokantaan. Se ei ole pullonkaula, mutta sekin kestää nykyversiossa noin sekunnin (2000 kommentilla). Ja tuo aika sitten kasvaa kun kommentteja/lukumerkintöjä tulee lisää.

Nykyversiossa on hölmöt 2 sisäkkäistä silmukkaa tietokannan päivityksen yhteydessä. Tuon sai optimoitua hashmapilla niin, että se vie 2000 kommentilla enää n. 0,02 sekuntia. Tuo aika sitten kasvaa lineaarisesti kommenttimäärän kasvaessa.

Eli päivittelen tämän kohta betaan. Nuo vastaavat ajat lienevät beta-koneella parempia; itse käytän läppäriä (jossa Intel i3).

In GitLab by @Smibu on Sep 22, 2014, 16:25

Alla olevan kommentin asiat on nyt betalla.

In GitLab by @Smibu on Sep 22, 2014, 18:03

@Smibu Onkos Betassa missään dokussa kiinni yhtä paljon dataa että voi kokeilla? – Vesa Lappalainen

In GitLab by @Smibu on Sep 22, 2014, 18:17

@vesal Ei vielä, teen vielä yhden optimoinnin ja teen sitten jonkun testidokun.

In GitLab by @Smibu on Sep 22, 2014, 18:22

@Smibu Senhän voisi laitata siihen 1-dokuun siinäkin, koska siinä on melkein sama sisältö kuin TIMissa. Ja silloin jos kloonaan TIMin kannan, niin menisikö muistiinpanota ja "olen lukenut" samalla samaan suuruusluokkaan? – Vesa Lappalainen

In GitLab by @Smibu on Sep 22, 2014, 21:00

@vesal Nyt tuolla dokussa: http://tim-beta.it.jyu.fi/view/2 on mulla ja sulla kaikissa kappaleissa lukumerkintä eli yhteensä melkein 4000. Testasin editointia; eli siinä kestää vajaa 10 sekuntia.

Eli nyt suurin pullonkaula editoinnissa lienee tuossa Ephemeralin mätsäysalgoritmissa. Omalla koneella tuo mätsäys kestää n. 15 sekuntia. Tuo aikaisemmin mainittu 6 sekuntia tuli yksinkertaisesta testidokumentista, jossa jokaisen kappaleen sisältö oli melkein pelkkä numero.

Jälkimmäistä kysymystä en ihan ymmärtänyt?

In GitLab by @Smibu on Sep 22, 2014, 21:12

mitäs kaikkea yhden kappaleen editoinnista mätsätään? – Vesa Lappalainen

In GitLab by @Smibu on Sep 22, 2014, 21:20

Niin, ajattelin siis että jos ois kopsinut TIMistä tietokannan (ja käyttäjät) ja kun betan doku 1 on kopio TIMin doku 1:stä, niin olisi saanut samalla live-datalla kokeilla tuota.

Mutta aika paljon on 10 sek viive pikkukappaleen editoinnista. Mikä tuossa on mahdollisuus saada tuota takaisin lähes reaaliaikaiseksi? – Vesa Lappalainen

In GitLab by @Smibu on Sep 23, 2014, 10:46

Niin, ajattelin siis että jos ois kopsinut TIMistä tietokannan (ja käyttäjät) ja kun betan doku 1 on kopio TIMin doku 1:stä, niin olisi saanut samalla live-datalla kokeilla tuota.

Niin joo, tuon voi varmaan jossain vaiheessa tehdä. Betan kanta kannattaa kuitenkin laittaa talteen, jos siihen tarvii palata. Sieltä voisi ottaa nuo tärkeimmät testausdokumentit talteen ja lisätä ne uudestaan kun kannan on siirtänyt.

Mutta aika paljon on 10 sek viive pikkukappaleen editoinnista. Mikä tuossa on mahdollisuus saada tuota takaisin lähes reaaliaikaiseksi?

Pitäisi olla helppoa, koska yhtä kappaletta muokatessa/lisätessä/poistaessa voi nopeasti saada selville kappalemäärän muutoksen ja indeksin, jolloin mäppäyksen voi päätellä suorittamatta algoritmia. Voin tänään kokeilla ainakin tämän tehdä.

Koko dokumenttia päivitettäessä manage-sivulta tilanne on hankalampi. Silloin pitäisi mätsäysalgoritmia parantaa jotenkin, jos tuota haluaa nopeuttaa. En tiedä, olisiko Villellä ideoita siihen. Yleensähän kappaleet vaihtavat paikkaa korkeintaan +/- 2 indeksiä, eli tuota tietoa voisi ehkä hyödyntää.

mitäs kaikkea yhden kappaleen editoinnista mätsätään?

Tällä hetkellä se tosiaan mätsää kaikki kappaleet.

In GitLab by @Smibu on Sep 23, 2014, 11:04

Nyt kysymys on siis se, että palajonko paukkuja käytetään nykyisen optimointiin ja mitä voitettaisiin uudella kannan järjestelyllä. Jos nykyisellä päästiin 10 sek viiveeseen muokkauksessa, niin voi elää sen kanssa tämän viikon, jos sitten saadaan uusi ja nopeampi, jossa muokkaus on 1 sek suuruusluokkaa.

Jos asioita haluaa kokeilla TIMin kannalla ja betassa on säästettävää, niin entä TIM-alfa suorituskykytestejä varten. syntyisikö se nopeammin? Ja jos haluaa kiertää uusien nimien luomisen, niin ihan vaan tim.it.jyu.fi:8081 yhteen konttiin.

Muta tosiaan ykköskiire olisi miettiä miten päästään nopeiten järkevään käyttökelpoiseen tulokseen, oliko nuo tietokantamuutokset mitä suuniteltiin, riittäviä vai tuleeko niiden kanssa samoja ongelmia? – Vesa Lappalainen

In GitLab by @Smibu on Sep 23, 2014, 16:30

@vesal Betalla on nyt tehty tuo yksittäisten kappaleiden muokkaamisen optimointi. Kotoa kokeiltuna muokkausviive on n. 1 sekunti.

Muta tosiaan ykköskiire olisi miettiä miten päästään nopeiten järkevään käyttökelpoiseen tulokseen, oliko nuo tietokantamuutokset mitä suuniteltiin, riittäviä vai tuleeko niiden kanssa samoja ongelmia?

Tuossa yllä olevassa suunnitelmassa tarvitaan joka tapauksessa samanlaista mäppäysalgoritmia, eli dokumentin päivittäminen manage-sivulta kestäisi siinäkin tuon 10 sekuntia (viimeistään siinä vaiheessa, kun suurimmassa osassa dokumentin kappaleista on muistiinpano/kommentti/lukumerkintä). Eli ennen pitkää mäppäysalgoritmia pitäisi luultavasti saada nopeammaksi.

Jos asioita haluaa kokeilla TIMin kannalla ja betassa on säästettävää, niin entä TIM-alfa suorituskykytestejä varten. syntyisikö se nopeammin? Ja jos haluaa kiertää uusien nimien luomisen, niin ihan vaan tim.it.jyu.fi:8081 yhteen konttiin.

Joo no tuolla nginxissä taitaa itse asiassa olla tuo tim-dev.it.jyu.fi-osoite, johon voisi laittaa vielä kolmannen version TIMistä pyörimään. Pohjalle voisi kloonata TIMin kannan.

In GitLab by @Smibu on Sep 29, 2014, 09:19

Lisäsin dokuun 1 taas csPlugineja. Nyt dokun saaminen View-tilaan kestää jo 16 sek. Kun Chromen networkistä katsoon, niin kun tilataan view/1, niin menee 12 sek ennenkuin tulee ensimmäinen pyyntö selaimelta. Eli tämän ajan TIM puuhailee taustalla jotakin muuta, sitten loppu 4 sek on js:ien ja kuvien hkemista selaimelta.

Pitäisi tutkia miten tuota 12 sek saa pienemmäksi. Tiedostoon /opt/cs/images/log.txt tulee kaikki csPluginille tehnyt pyynnöt ja siellä näyttäisi osa ajasta menevän ihan noihin csPluginein kutsuihin, mutta sitten tule välillä 5 sek tauko ja kutsut jatkuvat.

Ensimmäinen nopeutusyritys voisi olla pyytää kaikki csPluginein html-palat yhdellä kutsulla ja lisätä plugin rajapinnan reqs osaan joku multihtml=true ja silloin TIM pyytää joukon html.osia antamalla kaikki /html-paramterit johonkin taulukoon tms. sullottuna.

@Smibu @tomijkarppinen – Vesa Lappalainen

In GitLab by @Smibu on Sep 30, 2014, 11:56

Jaan tämän kortin useampaan osaan, ettei suotta paisu.

In GitLab by @Smibu on Oct 5, 2014, 18:21

En tiedä oikein mihin korttiin, mutta laintan tänne niin joku voi siirtää: Eli nykyinen html on varsin tuhlailevaa, esim yhden kuvan takia tulee seuraavat rivit:

<div id="par-294" class="paragraph ng-scope" ng-repeat="par in paragraphs" ng-init="parIndex = par.par">
            <div style="" class="content 294" compile="" ng-bind-html="par.html | to_trusted"><div id="1.k4" data-plugin="/showImage" class="ng-scope"><img height="270" src="/static/ohj1/images/luentomonistecsUusin_htm_m12339dd1.png">
<p class="footer">Kuva 4: Kaksi lumiukkoa</p>
</div></div>

            <div ng-controller="NoteCtrl" class="ng-scope">
                <div class="notes">
                    <!-- ngRepeat: note in par.notes -->
                </div>

                <div class="readline modified" ng-click="setAsRead(1, par)" ng-class="par.readStatus" title="Click to mark this paragraph as read"></div>
                <button ng-show="!m.showEditor" class="addNoteButton" ng-click="addNoteButtonToggled()">Note / comment</button>

                <!-- ngIf: m.showEditor -->
            </div>
        </div>

Tuossa melkein pitäisi päästä siihen, että on yksi div joka hoitaa sekä pluginin parentin roolia, että paikan JS:lle löytää tuohon liittyvät asiat. Jos HTML:än tuottaa itse, tuota voisi varmaan lyhentää huomattavasti. Silloin se vähentää siirrettävän datan määrää. Note nappikin voisi olla vain yhden keraan koko dokussa ja se liikkuu sen kappaleen luokse, missä sitä tarvitaan (klikkaus kappaleessa tms siirtää napin kappaleen luokse tai Miten Sepon suunniltelmassa olikaa. Itse noteja harvoin on joka kappaleen kohdalla, joten notet voisi sijoitella joko palvelimen päässä tai sitten JS:llä tarvittaviin kohtiin.

Korttiin (#161) kirjoitin View/Edit -tilojen yhdistämisestä ja tämän homman voisi integroida siihen.

Tuosta tekeekö palvelin kokonaisen valmiin html vai antaako se kerralla html:än jossa on perusdoku + käyttäjän muutokset, voisi olla kaksi versiota joita sitten tarjotaan asiakkaille heidän päätelaitteidensa mukaan. Työasema taiaa olla nopeampi sijoittelemaan noita lukumerkintöjä kuin palvelin, eli silloin kuormaan enemmän selaimelle. Kännykkä taas on todella hidas noissa, eli silel pitäisi pystyä tarjoamaan mahdollisimman valmis html, jota ei juurikaan tarvitse (ainakaan heti, jos taustalla menee, niin ok) JS:llä muokata. Eri juttu tietysti editoinin yhteydessä kun muuttuntu kappale laitetaan omalla kohdalleen. – Vesa Lappalainen

In GitLab by @Smibu on Oct 13, 2014, 08:05

ipadissä kommentin lisääminen kestää melkein 30 sek – Vesa Lappalainen

In GitLab by @Smibu on Oct 19, 2014, 16:14

Tuo http://tim.it.jyu.fi/read/57148?rand=23994 kestää n. 0.7 sek vaikka on tyhjä joukko. – Vesa Lappalainen

In GitLab by @Smibu on Oct 19, 2014, 16:26

Tuo notesien hakeminen:

http://tim.it.jyu.fi/notes/1?rand=42796

kestää mulla peräti 3.5 sek. – Vesa Lappalainen

In GitLab by @Smibu on Oct 19, 2014, 17:18

Mun pluginien hinta Ohj1-monisteessa on n. 1 sek yhteensä. Tuota visi hieroa pienemmäksi niin, että ei antaisi Angularin tehdä niin paljoa tuossa, vaan palauttaisi HTML-pyyntöön valmista HTML:ää, mihin Angularin ei tarvitse enää tehdä mitään.

Kuitenkin n. 10 sek VIEW ajasta tuo on vielä vain 10%, eli en tuohon rupea ennenkuin muut pullonkaulat on selvitetty ja ollaan jossakin n. 4 sek ajoissa. Silloin tuosta saatavalla ehkä 0.5 sek pudotuksella on silmin nähtävää hyötyä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 12, 2015, 10:05

@vesal @tomijkarppinen Kaikki nuo on käsittääkseni tehty, joten siirrän tämän tuotanto-osioon.

In GitLab by @Smibu on Nov 14, 2017, 01:06

closed

TIM-JYU / TIM

Suorituskyky #926

Checklist