Etapp 6 - Achaad/Weatherly GitHub Wiki

Ülesanne Etapp Punktid
Päringute arvu ja mahu piiramine 6. 6p
Automaattestid 6. 6p
Jõudlustestid 6. 6p
Kokku Punkte 18p

Päringute arvu ja mahu piiramine

Veebirakendus oli kontrollitud kasutades Google PageSpeed. Esialgne Google hinne on 46 punkti, mis on nende skaala järgi aeglane (0-49). Veebilehitseja laadis järgmiseid faile alla:

  • JavaScript - 787 KB
  • CSS - 180 KB
  • Font - 55.2 KB
  • HTML - 2 KB
  • Image - 365 B
  • Redirect - 205 B

Total: 1.0 MB

  • Veebilehe laadimiseks kuulus 6.9 sekundit.
  • First Contentful Paint: 5.1s
  • First Meaningful Paint: 5.1s
  • First CPU Idle: 5.1s
  • Time to Interactive: 6.4s

Google soovitused:

  1. Enable text compression
  2. Minify JavaScript
  3. Use data caching
  4. Eliminate render-blocking issues
  5. Reduce server response time
  6. Defer unused css (materialize.css)

Lahendused:

  1. HTML, CSS, XML, JavaScript, JSON on nüüd pakitud arhiivi, mis vähendab nende suurust ja suurendab alalaadimise kiirust.
  2. JavaScript on minimiseeritud ehk viidud kujule, kus on eemaldatud kõik tühikud ja uued jooned. See oluliselt vähendab JS faili. Plaanis oli ka muuta faili sees muutujate ja funktsioonide nimetused väiksemateks samaaegselt obfustseerides koodi. See ei ole tehtud, sest ei leidnud Gradle plugin'i, mis teeks seda, ning ei saanud automatseerida seda protsessi. Nende kahe lahenduse kasutamise tulemused (failide suurused):
  • JavaScript - 91.5 KB (88.4% väiksem)
  • CSS - 27.6 KB (84.67% väiksem)
  • Font - 55.2 KB (muutusteta)
  • HTML - 1.8 KB (10% väiksem)
  • Image - 412 B (12% suurem)
  • Redirect - 205 B (muutusteta)

Total: 176.8 KB (82.4% väiksem)

  1. Andmed on salvestatus käšši ja neid hoitakse seal 2 minutit. Nii väike aeg on valitud arvestades sellega, et rakenduse eesmärk on alati näidata värskemat ilma.

  2. Seda lahenduse ei kasutatud, sest selleks on vaja loobuda materialise.css'st.

  3. Reduce server response time. Seda on keeruline teha kuna server ei ole füüsiliselt kättesaadav. Serveril ei tööta ebavajalikke protsesse, mis võiksid põhjustada pikemat ooteaega. Back-end on optimiseeritud ja seda suurem optimiseerimine nõuaks liiga palju tööd, kuid ei oleks andnud piisavalt suurt kiiruse juurdekasvu.

  4. Sama nagu 4. punkt.

Lisaks muutsime back-end'i, et ta kasutaks HTTP/2 protokolli, mis peaks kiirendama andmete allalaadimist.

Tulemused:

  • Veebilehe laadimiseks kuulus 3 sekundit. (56.5% kiirem)
  • First Contentful Paint: 2.7s (47% kiirem)
  • First Meaningful Paint: 2.7s (47% kiirem)
  • First CPU Idle: 2.8s (45% kiirem)
  • Time to Interactive: 2.9s (54.7% kiirem)

Speed Score: 92 (fast)

Optimiseerimise tulemusena vähenes allalaaetud failide suurus 82.4% võrra, ning rakenduse töö kiirenes ca 55% võrra.

Automaattestid

Kasutades Selenium Webdriverit kirjutati tested, mis katavad kogu back-end funktsionaalsuse ja ka osa front-end funktsionaalsuset.

Testid: https://github.com/Achaad/Weatherly/blob/master/src/main/java/com/weatherly/demo/services/UnitTests.java

Kõik testid testid läksid viimase commiti järgselt läbi.

Jõudlustestid

Testid enne optimiseerimist:

loadimpact.com lehel weatherly.me:

Test 1

5 minutit, aina kasvav kasutajate arv(stress test). Kõige tihedamal hetkel tehakse 9 küsimist sekundis, keskmiselt 7 küsimist sekundis. Keskmine ooteaeg: 75 ms, suurim ooteaeg: 91 ms.

eeltest1

Pärast optimisatsiooni:

images/test1.png Keskmine ooteaeg: 75 ms Suurim ooteaeg: 77 ms

Test 2

5 minutit, pidevalt suur kasutajate arv(load test). Üsna järjepidev 8 küsimist sekundis. Keskmine ooteaeg: 76 ms. Suurim ooteaeg: 175ms. Selle testi puhul oli huvitav see, et kõige suurema koormusega ajal probleeme polnud, kuid kui kasutajad lahkusid, suurenes küsimise aeg märkimisväärselt.

eeltest2

Pärast optimisatsiooni:

images/test2.png Keskmine ooteaaeg: 75 ms Suurim ooteaeg: 76 ms Võrreldes eeltestiga suurenes rakenduse stabiilsus ja ooteaeg ei suurenenud.

Test 3

3 minutit, simuleerib järsku kasutajate arvu suurenemist (spike test). Tippajal keskmiselt 8 küsimist sekundis. Keskmine ooteaeg: 92ms, suurim ooteaeg: 1,29 s. Enne massilist kasutajate tulekut hüppas ooteaeg korraks väga kõrgele. Kasutajate massiline pealetulek suurendas ooteaega veidi ning see ajakasv kestis kuni peaaegu lõpuni välja. Lõpus normaliseerus ooteaeg.

eeltest3

Pärast optimisatsiooni:

images/test3.png Keskmine ooteaeg on stabiilselt 76 ms. Külastajate arvu suurenemine ei mõjutanud rakenduse tööt.