search

giellalt / bugzilla-dummy

0 stars 0 forks source link

sma-leksa "nytt sett" tar 6-8 sekund (Bugzilla Bug 1173) #1087

Closed albbas closed 13 years ago

albbas commented 13 years ago

This issue was created automatically with bugzilla2github

Bugzilla Bug 1173

Date: 2011-10-07T17:36:21+02:00 From: Trond Trosterud <> To: Ryan Johnson <> CC: berit.a.baal, ciprian.gerstenberger, heli1401, lene.antonsen, trond.trosterud

Last updated: 2011-10-18T10:04:09+02:00

albbas commented 13 years ago

Comment 5280

Date: 2011-10-07 17:36:21 +0200 From: Trond Trosterud <>

Etter at vi fekk nye språkpar denne veka (utan _FIN og _SWE, men med reelle ord) har tida det tar å få nytt 5-sett i leksa gått opp til ca 6-8 sekund (det varierer litt).

For å repetere:

  1. Gå til sma-oahpa leksa
  2. Trykk "Nytt sett"
  3. Tell til åtte
  4. Få eit nytt sett

Dette er for lang tid.

For andre sett enn "Sørsamisk til norsk" blir "Nytt sett"-knappen grå mens brukaren ventar. Det er for så vidt positiv (hindrar henne i å trykke fleire gonger, og dermed forlenge dei 8 sekunda).

Vi håpar dette er ein bug, og at det er mogleg å få ned reaksjonstida.

Alternativt kanskje skifte datamaskin, eller programvareversjon.

albbas commented 13 years ago

Comment 5284

Date: 2011-10-08 00:55:01 +0200 From: Ryan Johnson <>

Hei,

Eg sjekka og såg at database engin var MyISAM og ikkje InnoDB. InnoDB er mykje raskare. Då eg bytta eit par tables til InnoDB var det plutseleg raskare. Cip hev forandra default-storage-engine setting i /etc/my.cnf til InnoDB, og no eg lader databasen att.

Det er noko som kan forandrast på ein eller to eller kor mange som helst tabler (utan å forstyrra programmer som nyttar deim), men trudde at det skulle vera betre om det gjerast automatisk, elles må eg forandra database engine kvar gong me fornyer databasen. Kan bety også at smeoahpa er raskare når nokon fornyer den.

Om det er ikkje raskt nok då, skal eg sjå på queryene og andre mysql settings. Kan vera at eg kan optimisera databasen og smaoahpa litt meir. :)

albbas commented 13 years ago

Comment 5286

Date: 2011-10-08 06:51:57 +0200 From: Ryan Johnson <>

Okei, prøv den no. Eg testa og det ser litt raskare ut, og mens eg såg på top, nytta MYSQL mindre minne for å finna ord... Men, nettet er litt tregt heime, og eg er ikkje i Noreg, då kan eg ikkje segja om det er tregt fordi systemet lager ei lista av spørsmål, eller om det er tregt fordi det sender eit ferdig HTTP-request. :)

albbas commented 13 years ago

Comment 5289

Date: 2011-10-08 08:17:51 +0200 From: Trond Trosterud <>

Nede i 3 sekund no.

albbas commented 13 years ago

Comment 5290

Date: 2011-10-08 08:34:34 +0200 From: Ciprian Gerstenberger <>

Det stemmer, jeg har sjekket selv. Men 3 sek er også litt for mye for slik operasjon.

(In reply to comment #3)

Nede i 3 sekund no.

albbas commented 13 years ago

Comment 5291

Date: 2011-10-08 23:11:49 +0200 From: Ryan Johnson <>

Okei, eg gjorde litt meir optimisering (eller det ser ut som det hev funka på maccen min og dvelopment maskina mi):

Når eg starta, viewen til leksa var slik:

$ 32 queries in 0.616 seconds 32 queries in 0.206 seconds 32 queries in 0.216 seconds 32 queries in 0.206 seconds 32 queries in 0.22 seconds 38 queries in 0.223 seconds 37 queries in 0.211 seconds 37 queries in 0.212 seconds 37 queries in 0.202 seconds 39 queries in 0.32 seconds 37 queries in 0.296 seconds 37 queries in 0.238 seconds

... osv.

Men nå ser det ut sånn:

$ 33 queries in 0.028 seconds 32 queries in 0.02 seconds 33 queries in 0.018 seconds 32 queries in 0.023 seconds 44 queries in 0.016 seconds 38 queries in 0.014 seconds

Det var ikkje mogleg å minka antal queryer enno, men eg minka arbeid dei gjer. Kan sjå på det litt meir om det trengst. Skal installera på victorio snart og testa.

Eit anna spørsmål å løysa kan vera: kvifor køyrer det raskare på ei virtuel maskin, enn på victorio (som hev mykje meir memory og disk space...) :)

albbas commented 13 years ago

Comment 5300

Date: 2011-10-10 18:09:57 +0200 From: Ryan Johnson <>

Sida victorio vart restarta det ser ut til meg som det køyrer raskare om man vel smanob, smaswe, smafin, men motsatt er det litt meir tregt. Eg er litt lengre bort, og... Korleis ser det ut på dykkar sida?

albbas commented 13 years ago

Comment 5351

Date: 2011-10-15 03:13:24 +0200 From: Ryan Johnson <>

Den ser ut til å ikkje vera noko problem no. Eg lukker buggen, men om det dukker opp andre problem med hastigheit, kan nokon opna den att, eller lag ein ny bugg. Eg trur at Morfa-B og Morfa-R er so raskt som dei kan vera no utan fleire timar arbeid og testing for å sjå at morfa lager spørsmål på samme vis. Morfa-B og -R er raske no, men om nokon vil at dei går raskare kan me tala om det etter lansering.

Hastigheit kan vera løyst på andre visor og, f. eks., om me får mod_wsgi på plass før lanseringa. Andre løysningar kan vera: bruk av postgresql til staden av mysql (eg hev litt meir kunnskap i postgres, men kan segja at den er raskare med django, og litt meir flink med index-tabler), bruk av nginx til staden av apache (nginx er fantastisk og rask).

Eg synest elles at systemet køyrer fint som det er no, men me får sjå når det er 10-15 studentar som nyttar oahpa samtidig under eit kurs.

Problemet med Leksa er no fiksa, då lukker eg buggen. Om samtale om hastigheit må halda fram, kan me ta det ved epost utafår bugzilla. :)

R

albbas commented 13 years ago

Comment 5353

Date: 2011-10-15 08:25:35 +0200 From: Trond Trosterud <>

Eg ser noko merkeleg når eg testar for kor lang tid ting tar i Leksa:

sma>nob 2 sma>swe 2 sma2fin 2 nob>sma 6 swe2sma 6 fin2sma 6

Med andre ord: Nytt sett frå sma til eit anna språk tar under 2 sekund (og er akseptabelt), mens nytt sett når språkparet er frå eit anna språk og til sma, tar det 6 sekund, som før.

Så det ser ut som om fiksen din berre gjeld ei retning.

albbas commented 13 years ago

Comment 5359

Date: 2011-10-15 18:17:26 +0200 From: Ryan Johnson <>

Hmm, interessant! Eg skal kikke på den att. Det ser ut som hastigheit til sql-queryane kan vera berre ein del av problemet.

Det kan også vera at det er framleis noko me kan gjera med MySQL konfigurasjon. På maskina mi går det slik med sqlite på mac:

35 queries in 2.18 seconds <--- smaswe 32 queries in 0.041 seconds 32 queries in 0.04 seconds 32 queries in 0.04 seconds 32 queries in 0.106 seconds <--- no byrjar med swesma 32 queries in 0.049 seconds 32 queries in 0.046 seconds 32 queries in 0.051 seconds

Og no med mysql på ein linux vm:

32 queries in 0.247 seconds <--- smaswe 32 queries in 0.028 seconds 32 queries in 0.025 seconds 32 queries in 0.021 seconds 32 queries in 0.302 seconds <--- swesma 32 queries in 0.024 seconds 32 queries in 0.023 seconds 32 queries in 0.02 seconds

Poenget er ikkje å visa at ein eller annan databaseprogram er raskare en ein annan, men at det kan gå litt tregt når ein flytter til eit nytt språkpar. Fordi det skjer på to ulike databaseprogrammer, kan det vera at problemet er i python/django i nokon stad. Eg skal sjå på den, og då prøve å finne på

Eg skal iall fall finne ei løysing i python-koden først, og då finne ut kva eg kan gjera med mysql konfigurasjon om det er noko som kan optimiserast.

albbas commented 13 years ago

Comment 5360

Date: 2011-10-15 20:46:30 +0200 From: Ryan Johnson <>

Eg hev no arbeidd med visa django nyttar informasjon det får frå databasen etter queryane og fått ein auking i hastigheit, som eg fekk på virtuelmaskina mi med MySQL. Det ser ut no som det går nesten so fort i sma-X som i X-sma. Om det er ikkje slik, det er framleis nokre ting eg kan gjera.

Det er no berre å sjekke på victorio, men nokon må omstarta apache først. Eg skal venta å gjera ein svn up på victorio før eg veit at nokon kan omstarta den straks etterpå.

albbas commented 13 years ago

Comment 5369

Date: 2011-10-17 09:41:07 +0200 From: Ryan Johnson <>

HA HA, eg fann problemet!

Her er ein query frå swesma:

SELECT smadrill_word.id, smadrill_word.lemma FROM smadrill_word INNER JOIN smadrill_word_semtype T4 ON (smadrill_word.id = T4.word_id) INNER JOIN smadrill_semtype T5 ON (T4.semtype_id = T5.id) INNER JOIN smadrill_wordtranslation ON (smadrill_word.id = smadrill_wordtranslation.word_id) WHERE (NOT ((smadrill_word.id IN (SELECT U1.word_id FROM smadrill_word_semtype U1 INNER JOIN smadrill_semtype U2 ON (U1.semtype_id = U2.id) WHERE U2.semtype IN ('exclude_smanob', 'mPERSNAME', 'PLACES')) AND smadrill_word.id IS NOT NULL)) AND T5.semtype IN ('HUMAN') AND smadrill_wordtranslation.language = 'sma' AND smadrill_word.language = 'swe' ) ORDER BY RAND() LIMIT 10 ;

På VM:n min køyrer den i 0.15 sec, men på vic var det framleis 3.86 sec. Då kan det ikkje vera eit problem med mange JOINs, osv.

Eg såg på indexes til dei ulike tablene som er med i queryen:

vic:

mysql> SHOW INDEXES FROM smadrill_word ; +---------------+------------+------------------------+-------------+ | Table | Non_unique | Key_name | Cardinality | +---------------+------------+------------------------+-------------+ | smadrill_word | 0 | PRIMARY | 13283 | | smadrill_word | 1 | smadrill_word_6c63d3c2 | NULL | | smadrill_word | 1 | smadrill_word_75853655 | NULL | | smadrill_word | 1 | smadrill_word_58909fea | NULL | | smadrill_word | 1 | smadrill_word_feffdf0 | NULL | +---------------+------------+------------------------+-------------+ 5 rows in set (0.00 sec)

VM:

mysql> SHOW INDEXES FROM smadrill_word ; +---------------+------------+------------------------+-------------+ | Table | Non_unique | Key_name | Cardinality | +---------------+------------+------------------------+-------------+ | smadrill_word | 0 | PRIMARY | 13283 | | smadrill_word | 1 | smadrill_word_6c63d3c2 | 13283 | | smadrill_word | 1 | smadrill_word_75853655 | 3 | | smadrill_word | 1 | smadrill_word_58909fea | 13283 | | smadrill_word | 1 | smadrill_word_feffdf0 | 6641 | +---------------+------------+------------------------+-------------+ 5 rows in set (0.00 sec)

Og so var det ein 'AHA' moment.

Cardinality til smadrill_word, smadrill_wordtranslation, smadrill_word_semtype (og truleg andre tabler og) er NULL på vic, men ikkje på VM:n min. Ei midlertideg løysing for å fiksa denne er å køyra fylgjande kommento:

analyze table TABLENAME ;

Etter å ha gjort dette med tablene køyrer samme queryen på victorio i ~.48 sec.

No er det berre å finne ut kvifor Cardinality har vorte til NULL, og då får me løysing. Om ein prøver no å trykkja på 'nytt sett' i grensesnittet køyrer Leksa veldig raskt.

Skal sjå på den litt meir seinare, men ville berre segja kva er statusen. :>

albbas commented 13 years ago

Comment 5383

Date: 2011-10-18 10:04:09 +0200 From: Trond Trosterud <>

Vi er nede i under to på begge.