Web-palvelun kuormitustestaus tarkoittaa testiä, jolla pyritään selvittämään, kestääkö palvelu sille arvioidun käyttäjämäärän aiheuttaman liikenteen.
Kuormitustestaus tulee ajankohtaiseksi useasti juuri julkaisun kynnyksellä – hyvällä tuurilla jopa muutamaa viikkoa ennen. Tähän aikaan palvelun kehittäjät ovat kiireisiä tekemässä sitä kuuluisaa viimeistä 20% joka vie 80% työajasta, joten työ saatetaan jopa ostaa ulkopuoliselta kuormitustestaukseen erikoistuneelta yritykseltä. Erikoistumisesta huolimatta tämä testaus tehdään usein puutteellisesti tai väärin.
Kuormitustestaus pommittamalla
Tarkastellaan ensin yksinkertaisempaa tapaa kuormitustestata, jota kutsun tässä yhteydessä pommittamiseksi. Pommittamisessa selvitetään kuinka monta palvelupyyntöä web-palvelin pystyy onnistuneesti palvelemaan sekunnissa. Tyypillisesti tällainen kuormitustestaus suoritetaan jollakin tunnetulla työkalulla, kuten JMeter ja Gatling tai SaaS-palvelulla kuten BlazeMeter.com ja Loader.io. Palvelusta identifioidaan muutamia URL-osoitteita, joiden oletetaan saavan eniten liikennettä. Tällaisia osoitteita ovat mm. REST-rajapinnat, joista selaimet tai muut palvelut hakevat tietoja.
Palvelupyyntöjen onnistumisen lisäksi pommittamisessa seurataan mm. keskimääräistä aikaa ja hajontaa, jossa palvelupyynnöt valmistuvat. Myös vastauksien tyyppejä seurataan, kuten kuinka monta pyyntöä peruuntuu aikakatkaisun tai muun virheen vuoksi. Työkalut tarjoavat erilaisia kojelauta näkymiä, joista lukemia on helppo seurata keskiarvojen, persentiilien ja jopa graafien muodossa.
Koska pommittaminen on suhteellisen kevyttä, on luultavasti jopa mahdollista löytää yläraja, jossa vastausajat ovat liian suuria kestoltaan tai virheitä on liikaa. Tällöin kehittäjät ehtiessään korjaavat pullonkaulan ja testaus voidaan suorittaa uudestaan, jolloin päästään korjaamaan seuraava pullonkaula. Useasti tällaiseen yksinkertaiseen testaamiseen ei tarvita edes ulkopuolista yritystä, vaan tämä voidaan hoitaa kehittäjien tai testaajien toimesta. On toki hienoa, että edes joskus testataan ja korjataan, mutta valitettavasti todellisia pullonkauloja pommittaminen löytää kuitenkin vain näennäisen tehokkaasti.
Internet on muuttunut
Kun edellä mainittu Apache JMeter julkaistiin vuonna 1998 oli Internet huomattavan eri näköinen. Sivut olivat usein fyysisiä .html -päätteisiä tiedostoja web-palvelinten kovalevyillä, ja JavaScriptiä käytettiin lähinnä siirtämään animoitua GIF-hevosta käyttäjän kursorin perässä. 20 vuotta myöhemmin puhumme web-palveluista näiden web-sivujen sijaan. Näitä palveluita tuotetaan jakamalla jopa kehitystiimi kahtia backend- ja frontend-kehittäjiin. Loppukäyttäjän näkemä sivusto syntyy dynaamisesti vasta selaimessa usein usean kymmenen palvelupyynnön tuloksena. Lisäksi palveluissa on linkitettynä huomattavia määriä kuvia, tyylitiedostoja ja palvelun ulkopuolisia skriptejä, joilla mm. tuotetaan analytiikkatietoa. Esimerkiksi tätä kirjoittaessa www.hs.fi tekee noin 200 palvelupyyntöä etusivua ladattaessa. Suuri osa näistä palvelupyynnöistä tapahtuu asynkronisesti JavaScriptillä. Jotta JMeter tai vastaava matalan tason työkalu osaisi huomioida nämä pyynnöt, olisi sen osattava suorittaa palvelun JavaScriptit, kuten käyttäjän web-selain ne suorittaa. Eli toisin sanoen, jotta pommittaminen toisi ilmi todelliset pullonkaulat, olisi JMeteriin lisättävä kaikki 200 URL-osoitetta. Tämän lisäksi työkalun tulisi tehdä pyynnöt samassa vesiputousmaisessa järjestyksessä, jolla käyttäjän selain ne tekee (hs.fi:n tapauksessa n. 3 sekunnin aikana sopivissa ryppäissä).
Usein tässä vaiheessa kuulen argumentin: “kuvia ei sentään tarvitse ladata, sillä nehän tulevat sisällönjakeluverkosta (CDN), eivätkä suoraan ole tämän palvelun vaikutuspiirissä”. Jostain syystä testattaessa web-palvelun suorituskykyä usein siirrämme itsemme palvelun konesaliin ja unohdamme, että yksittäisen sivun latausnopeus on kokonaisuus, jossa käyttäjää ei – oikeutetusti – voisi vähempää kiinnostaa, kuinka hienosta sisällönjakeluverkosta kuvat tulevat.
Testaajina meidän tulee testata tilanne end-to-end, asettautumalla käyttäjän asemaan, jossa huomioidaan myös muiden palveluntarjoajien viiveet ja kokonaisverkkoliikenteen määrä, joka kaikista kuvista syntyy. Koska kehittäjillä on kiire, saattaa yllättäen kuvien CDN-jakelu vahingossa kytkeytyä pois päältä jne. Lisäksi kannattaa seurata liikennemäärää mm. mökkilaiturin 3G-yhteyden näkökulmasta.
Nauhoitetaan kerralla purkkiin
Kehittyneempi tapa testata on asentaa testaajan selaimeen lisäosa (tai käyttää välityspalvelinta), joka nauhoittaa kaikki palvelupyynnöt juuri sellaisena, kuin selain ne tekee. Käyttämällä nauhoitetta saadaan huomattavasti parempi kuormaprofiili, jota ajamalla esim. JMeterillä saadaan huomattavasti parempi näkyvyys (mutta ei vieläkään täydellinen) todellisiin pullonkauloihin. Nauhoitetta käyttämällä saamme sarjan hyvin staattisia palvelupyyntöjä, jotka suoritetaan toinen toisensa jälkeen ja myöhemmin työkalun kojelautanäkymästä näemme, että osa palvelupyynnöistä ei ollut onnistuneita (jos näemme). Tilannetta saatetaan yrittää parantaa muokkaamalla nauhoitetta mm. lisäämällä käsin satunnaisia taukoja pyyntöjen välille ja muuttamalla parametrisoimalla niitä, jolloin nauhoitteesta tulee hieman dynaamisempi ja sen kuormaprofiili vastaa enemmän todellisuutta. Keskeisin ongelma nauhoitteessa kuitenkin on se, että se on tehty yhdellä tietokoneella yhdessä hetkessä. Web-palveluiden ollessa monimutkaisia kokonaisuuksia, missä jopa sadat mikropalvelut muodostavat yhden kokonaisuuden, on nauhoite väistämättä vanhentunut jo, ennen kuin testaaja ehtii muokata siihen taukoja käsipelillä. Vaikka parhaita käytänteitä, kuten ohjelmakoodin jäädytystä (palvelua ei saa muokata testauksen aikana) ym. noudatettaisiinkin, niin yllä kuvailtu tapa testata, on käsityöstä johtuen erittäin kallis ja edelleen puutteellinen.
Käyttöliittymätestaus apuun
Astutaan hetkeksi ulos testausmaailman työkaluista ja tarkastellaan mitä ohjelmistokehityspuolella tehdään aiheeseen liittyen. Ohjelmistokehittäjät käyttävät (ideaalimaailmassa) kehitystyönsä tukena erilaisia testaustapoja: nopeita (satoja testejä sekunnissa) yksikkötestejä yksittäisille luokille tai funktioille ja käyttöliittymätestejä web-palvelun toiminnolle automatisoidulla selaimella. Käyttöliittymätestauksen de facto nimenä on ollut Java-pohjainen Selenium ja sen johdannaiset mm. Suomalainen Robot Framework ja Capybara. Käyttöliittymätestaus on toiminnallista testausta, jossa selain käynnistyy ja suorittaa halutun polun (kirjaudu sisään, klikkaa tuotteet, valitse ensimmäinen tuote, …) yhtä nopeasti, mitä kehittäjän omalla koneella pyörivä paikallinen kopio palvelusta pystyy sen suorittamaan. Varsinainen testi tehdään jonkin asteisella ohjelmoinnilla, jossa käskytetään jokainen yksittäinen toiminto (klikkaa kuvaa x, valitse listasta kolmas) yksi kerrallaan.
Jos vertaamme tätä käyttöliittymätestausta palvelupyyntönauhoitteisiin huomaamme, että yksinkertaisesti lisäämällä luonnollisia taukoja käyttöliittymätesteihin saamme tehtyä testin, joka lataa kaikki kuvat, suorittaa kaikki skriptit, eikä etene (suorita seuraavia palvelupyyntöjä), jos jollain kerroksella tapahtuu virhe tai suorituksessa menee liian kauan. Siis – käyttämällä käyttöliittymätestejä “väärin” saamme toistettua käyttäjien polut juuri sellaisena, kun ne ovat oikeastikin. Kuormitustestausta tästä saa yksinkertaisesti nostamalla samanaikaisten selaimien määrän kohti haluttua määrää käyttäjiä. Oleellisempana erona tässä menetelmässä onkin siis se, että keskiarvoisten latausaikojen ja persentiilien sijaan, voimme vihdoinkin vastata kysymykseen; “kuinka monta oikeaa yhtäaikaista käyttäjää palvelu pystyi palvelemaan hyväksyttävillä latausajoilla” selvällä, yksikäsitteisellä luvulla.
Supervisor Cloud ja SaittiTohtori.fi
Juuri tässä tavassa tehdä asiat ”väärin” on Supervisor Cloud Oy:n (Suomen markkinoilla myös SaittiTohtori.fi) monitorointipalveluiden perusta. Olemme tämän yksinkertaisen ajatuksen kanssa pilotoineet useiden asiakkaiden kanssa hyvin tuloksin – paras hetki on piloteissa ollut se, kun meille on kerrottu, miten “JMeterillä pahimmat pullonkaulat ovat jo löytyneet”, mutta palvelu sulaakin jo muutaman kymmenen selaimen jälkeen, jotka yllättävät tekemällä ne kaikki pienet asiat, mitä oikeakin ihminen tekisi. Yksinkertaisellakin ”klikkaa etusivulta satunnaista linkkiä ja vierittele rauhallisesti sivun loppuun, jossa klikkaat satunnaista linkkiä” testillä monistamalla aiheutetaan mittava määrä verkkoliikennettä, kun sen suorittaa muutama tuhat selainta.
Olemme kehittäneet mm. kustannustehokkaan testausalustan, jonka avulla voi nopeasti luoda sivuston suorituskykyä mittaavia testejä. Kun testi on valmiina ja toteuttaa halutun käyttäytymisen, voimme monistaa sen ajoon käyttäen hallinnoimaamme infrastruktuuria. Jakelemme testin ajoon tarvittaessa jopa tuhansille palvelintietokoneille ympäri maailmaa halutun kuormaprofiilin mukaisesti. Suomalaisia käyttäjiä ajatellen viimeaikoina avatut Google Cloudin Hamina ja Hetznerin Tuusulan konesalit tiputtavat testien verkkoviivettä, eli latenssia. Mikäli kaivataan vielä tarkempaa latenssin poistoa, voidaan testauskoneet lähettää myös konesaliin suoraan kohdepalvelinten viereen – ja käyttää kytkennöissä niitä kuuluisia kullattuja liittimiä…
Kaikki edellä kuvailtu teknologia ei – vielä – poista ihmistä prosessista. Ihmisen rooli kuitenkin muuttuu, kun käyttöliittymä otetaan testaamisen lähtökohdaksi – HTTP tilakoodit, URL:t ja FormData-objektit määrittyvät kuin varkain itsestään. Päästään testaamisen ytimeen: millaisia polkuja ne oikeat käyttäjät suorittavat ja millä suhteella? Kuinka kauan jokin yksittäinen toiminto saa kestää, eli koska selaimen välilehti sulkeutuu ja käyttäjää mallintava käyttöliittymätesti toteaa, että ehkä kilpailevalta verkkosivulta saa tämän asian nopeammin.
– Matti Paksula –
Supervisor Cloud Oy:n perustajajäsen ja CTO