05 May 2020

Qridin R&D:n kuulumiset etäkouluajalta

Mitä teimme, kun käyttö yli 30-kertaistui

Koulujen etäopetuksen alkaessa opettajat ottivat käyttöön digitaalisia työkaluja nopeasti. Yksi työkaluista, jonka käyttömäärä lisääntyi lähes räjähdysmäisesti oli myös Qridi. Peruskoulujen siirryttyä etäopetukseen päivän kiireisimmän tunnin käyttömäärä 20-kertaistui ensimmäisten etäkoulupäivien aikana ja viikon kuluttua lisäys oli jo 30-kertainen.

Qridi on hyvin tyypillinen verkkopalvelu, jossa asiakasohjelmistot tekevät pyyntöjä palvelimelle HTTP-protokollan mukaisilla viesteillä. Sen käyttöliittymänä on joko selain tai oppilailla erillinen älypuhelimeen asennettava sovellus. Palvelun käyttömäärä mitataan hyvin yleisesti palvelimelle tulevien HTTP-pyyntöjen määrällä ja, kuten yllä todetaan, määrä kasvoi hyvin nopeasti yli 30-kertaiseksi.

Hyvin suunniteltu järjestelmä on skaalautuva eli yksittäisen pyynnön käsittelyaika on sama yhtäaikaisten pyyntöjen määrästä eli järjestelmän kuormasta riippumatta. Tämä on tietenkin idealisaatio, reaalimaailman järjestelmissä kuormalle on maksimiarvo, jonka järjestelmä voi käsitellä ja lisäksi käsittelyajat kasvavat maltillisesti kuorman lisääntyessä. Skaalautuvuus toteutetaan usein rinnakkaistamalla järjestelmä, jolloin lisäkapasiteettia saadaan yksinkertaisesti lisäämällä tiedonkäsittelyresursseja. Huomattavaa on se, että skaalautuvuus lisää viivettä eli huonosti skaalautuva järjestelmä on pienellä kuormalla yleensä nopeampi kuin hyvin skaalautuva.

Mitä konkreettisia toimenpiteitä teimme käytön kasvaessa?

Lisäsimme palvelinten kapasiteettia eli otimme käyttöön lisää muistia ja lisää suoritinytimiä. Tämä oli nopea ja kustannustehokas toimenpide lisätä suorituskykyä. Tällä tavoin saimme myös lisäaikaa toteuttaa suorituskykyparannuksia itse ohjelmistoon, koska oli ilmeistä, että käyttömäärä kasvaa edelleen.

Huomasimme, että tietokantaan tehdään liikaa kyselyjä yhtä HTTP-pyyntöä kohden. Käytännössä joka pyynnölle tehtiin ainakin 2 “ylimääräistä” tietokantahakua: tarkistettiin käyttöjän istunnon voimassaolo ja haettiin pyyntöä tekevä käyttäjä. Tietokantahakujen määrää pystyttiin pienentämään huomattavasti käyttämällä välimuistia käyttäjille ja istunnoille. Välimuisti oli suhteellisen helppo toteuttaa järjestelmään eikä se monimutkaistanut järjestelmää liikaa.

Etätyössä kouluissa käytettiin paljon päiväkirjoja ja etenkin niihin lisättiin runsaasti ääntä, kuvia ja videoita. Tunnistimme päiväkirjan mediatiedostojen olevan pullonkaula ja tähän tehtiinkin kaksi suorituskykyparannusta: mediatiedoston metatietoa varten lisättiin vastaava välimuisti kuin istunnoille ja käyttäjille sekä päiväkirjan vanhojen merkintöjen hakua rajattiin. Aikaisemmin oli haettu kaikki päiväkirjamerkinnät, nyt ensin vain 3 uusinta kommentteineen. Tämä vähensi mediatiedostojen hakua merkittävästi, koska aikaisemmin kaikki oli haettu vaikka niitä ei välttämättä edes näytetty käyttöliittymässä.

Lisäksi käytössä oli koko ajan hälytykset liian hitaista kyselyistä joten pystyimme nopeuttamaan ilmi tulleita hitaita pyyntöjä yllämainittujen muutosten ohella.

Olisiko tähän voinut varautua ennakolta?

Teoriassa kyllä, käytännössä ei. Järjestelmien kuormitustestaukseen on olemassa useita työkaluja, mutta todellista käyttöä vastaavia testejä on todella työläs toteuttaa. Todellisen kuormituksen painottumista järjestelmän eri osiin on myös hyvin vaikea ennakoida. Esimerkiksi päiväkirjojen ja etenkin niihin lisättävien mediatiedostojen suosiota olisi ollut tässä tapauksessa hyvin vaikea tietää etukäteen. Täydellinen varautuminen kaikkeen mahdolliseen etukäteen on myös hyvin kallista. Tärkeintä on järjestelmän arkkitehtuurin joustavuus, järjestelmän helppo päivitettävyys ja tuotekehityksen reagointikyky. Hyvin paljon samoja asioita, jotka pätevät kaikkiin IT-alan organisaatioihin kaikissa tämänkaltaisissa muutoksissa, oli niiden perimmäinen syy mikä tahansa.

Kirjoittanut Jukka Pirinen, Tuotekehitys ja tietoturva

Qridi