Ruuhkautuuko verkkopalvelusi? Testaa etukäteen ja vältä hätä kädessä -tilanne

Miten verkkopalvelun ruuhkautumista simuloidaan?

Tarjolla on monenlaisia ratkaisuja verkkopalvelun kuormitustestausta varten. Useat niistä ovat kaupallisia ja yleensä vaikeita testata ennen ostopäätöksen tekemistä. Tästä syystä JMeteropens-in-a-new-tab on työkaluna hyvin suosittu. Se on avoimen lähdekoodin ratkaisu ja siten helppo ottaa käyttöön.

JMeter mahdollistaa HTTP liikenteen simuloimisen siten, että HTML dokumentin haettuaan se hakee myös tarvittavat assetit. Lisäksi JMeter voidaan ohjelmoida lukemaan HTTP vastauksista asioita, joita tarvitaan seuraavissa sivulatauksissa. Tällä tavalla voidaan simuloida CSRFopens-in-a-new-tab suojattua lomakkeen käyttöä ja tehdä rajapintakyselyitä, jotka tarvitsevat edellisen kutsun tietoja muodostaakseen seuraavia kutsuja. JMeterillä testattaessa keksien käyttö simuloidaan samalla tavalla kuin selaimen keksien käyttö.

JMeter testit voidaan ajaa omalta tietokoneelta, mutta varsinaiset ajot suositellaan tehtäväksi erillisillä testaajapalvelimilla. Testaajapalvelimet voidaan kytkeä keskenään, jotta kuormitus kohdistuu verkkopalveluun useista eri lähteistä (myös jopa eri maantieteellisistä sijainneista). Tällä varmistetaan, että yksittäisen testaaja palvelimen oma kuormitus ei muodostu pullonkaulaksi.

Testaussuunnitelma laaditaan yleensä palvelun analytiikkadataa hyödyntäen. Analytiikkadatasta voidaan tunnistaa käyttäjän yleisempiä käyttäjäpolkuja, joita testiskenaariossa pyritään mallintamaan. Mikäli palvelu on uusi ja aikaisempaa analytiikkadataa ei voida hyödyntää, voidaan skenaario luoda valistuneilla arvauksilla.

Varsinaisten käyttäjäpolkujen lisäksi on hyvä lisätä jonkinlaista satunnaisuutta, jotta testiskenaariosta tulee mahdollisimman hyvin todellisuutta vastaava. Satunnaiset sivulataukset siellä täällä voivat välillä herätellä verkkopalvelun välimuistiratkaisuiden suhteen. Verkkopalvelun haut ovat tässä myös mainio lisä.

Skenaariossa voidaan, ja on suositeltavaakin simuloida varsinaisten vierailijoiden lisäksi myös palvelun ylläpitäjiä. Kun palvelu on kovassa kuormituksessa ja sisällöntuottaja päättää tehdä sisältöön muutoksen, voi palveluun tulla hetkellinen resurssipula johtuen sisällöntuottajan tallennuksen aiheuttamasta välimuistin tyhjentymisestä.

Skenaariossa yleensä kuormitetaan siten, että kuormitusta lisätään pikkuhiljaa. 40 minuutin testissä 35 minuuttia lisätään käyttäjiä lineaarisesti, kunnes se saavuttaa annetun maksimikäyttäjämäärän. Kuormituksen aikana on syytä tarkkailla infrastruktuurin suoriutumista, joka antaa hyvää osviittaa siitä miten verkkopalvelun palvelimet kestävät.

Kuormituksessa seurataan kutsujen vasteaikoja ja suoritustehoa (throughput). Suoritusteho kertoo kuinka monta sivua verkkopalvelu pystyy tarjoamaan samanaikaisesti. Vasteajat taas kertovat, kuinka nopeasti kutsu saa vastauksen.

Kuormitustestauksessa pyritään tunnistamaan se piste, milloin suoritusteho lakkaa korreloimasta käyttäjämäärien kanssa. Kutsutaan tätä pistettä nimellä “turning point”. Tämä käännekohta suoritustehossa määrittyy kun löydetään se kohta , jonka jälkeen suoritusteho ei enää kasva, vaikka käyttäjämäärä kasvaisi. Turning point on siis piste, kun palvelin on saavuttanut maksimaalisen suoritustehon, joten vasteajat lähtevät nousuun ja palvelu ruuhkautuu.

Kun palvelu saavuttaa ruuhkautumispisteen, se tarkoittaa että verkkopalvelussa ollaan saavuttu pullonkaulaan. Syynä voi olla joko suoritin tai vielä yleisemmin verkon kaistanleveys. Tässä tapauksessa on syytä varmistaa kummassa päässä pullonkaula on.

Samoin kun verkkopalvelukin, myös testaajapalvelinten kuormitus voi testissä koitua pullonkaulaksi. Tällöin testaajapalvelimen suoritin, muisti tai verkko on liian heikko tuottaakseen haluttua kuormitusta.

Joskus ruuhkautuminen aiheuttaa verkkopalvelussa sovellusvirheitä. Se voi johtua muistin loppumisen lisäksi siitäkin, että kovassa kuormituksessa usean käyttäjän palveleminen voi luoda erilaisia lukkiutumisopens-in-a-new-tab (deadlock) tilanteita. Näitä on erittäin hankala todeta normaalissa kehitysoloissa, mutta ne ovat tunnistettavissa kuormitustestien avulla.

Miten varautua verkkopalvelun ruuhkaan?

Vessapaperipakkauksen mitat sekä sille dedikoitu hyllytila ovat tiedossa ennalta ja helpolla matemaattisella yhtälöllä saadaan tietää, kuinka paljon vessapaperia saadaan hyllyyn ja sitä kautta melko tarkka arvio kuinka monen asiakkaan ostohalut voidaan toteuttaa tietyssä aikaikkunassa.

Verkkopalveluiden “riittävyydessä” tilanne on huomattavasti kompleksisempi. Tiedät ehkä minkälaiset palvelimet on käytössä, mutta et ehkä ole tietoinen siitä miten paljon eri käyttäjät kuormittavat palvelua. Et varmaan myöskään tiedä, miten verkkopalvelu käyttäytyy ruuhkatilanteessa - ehkä jokin toiminto ei toimi oikein tai ollenkaan palvelun ollessa ruuhkautunut? Entä jos kohderyhmässässi tapahtuu jotain, joka saa käyttäjät yhtäkkiä vierailemaan verkkopalvelussa? Tilanne vastaa lähikauppiaan skenaariota, jossa hän tietää kyllä vessapaperipakkauksen ulkomitat, mutta kysyntään tulee niin valtava piikki, ettei kauppiaspolo (“suoritin”) ehdi edes kärräämään varastostaan (“muisti”) tavaraa siinä tahdissa, kun sitä asiakkaat haluavat (“verkko”). Ja vaikka kauppias ehtisi hyllyttämään vessapaperit, niin tavarantoimittaja ruuhkautuu eikä kykene toimittamaan tarvittavaa määrää paperia.

Oli kyseessä sitten kunta, virasto, lipunmyynti, kaikkien aikojen alepäivät, tieteen läpimurto, suuri kohu, tai muu spektaakkeli, niin kaikissa tapauksissa haluat todennäköisesti palvella kaikkia käyttäjiä ja vieläpä mahdollisimman hyvin ja ripeästi.

Paloturvallisuuteen liittyvissä poistumisharjoituksissa kokeillaan järjestelmän toimivuutta ja rakennuksesta poistumista. Samalla opitaan, mitä heikkouksia tilanteessa voi olla ja täten varautua paremmin pahan sattuessa. Kuormitustestausta voikin verrata poistumisharjoituksiin - siinä kartoitetaan “vaaran paikat” ja kartoituksen jälkeen nämä ongelmakohdat korjataan.

Tekemällä kuormitustestauksen, saat vastauksia kysymyksiisi ja verkkopalvelun kehitys- tai ylläpitotiimi pääsee harjoittelemaan tilannetta, joka tositilanteessa olisi kuumottavaa hoitaa. Samalla on tilaisuus testata verkkopalvelun automaattista skaalautuvuutta, joka on käytössä esimerkiksi Wunderin Silta ratkaisussa.

Fyysisessä maailmassa kauppaan jonotetaan jos tulee ruuhkaa ja myytävä tuote voi kertakaikkiaan loppua hyllystä, mutta digimaailmassa kaupan neliöitä, hyllyjä ja kassoja voidaan lisätä sitä mukaan kun asiakkaita ilmaantuu lisää.

Kuormitustestauksen ABC

• Kukin käyttäjä tekee kutsuja ja ne kuormittavat eri tavoin verkkopalvelua.
• Vasteajat koostuvat muistin ja kiintolevyn nopeuden, suorittimen ja verkon yhteisvaikutuksista. Muistin ylikuormitus voi joskus aiheuttaa virhetilanteita, jotka näkyvät käyttäjälle vaikkapa Internal Server Error 500 -ilmoituksena
• Kuormitusta voidaan simuloida eri työkaluin, esim JMeterillä.
• Kuormitustesti kannattaa suorittaa useista testaajapalvelimista, jotta yksittäisen testaaja palvelimen kuormituskyky ei muodostu testin pullonkaulaksi.
• Kuormitusskenaarion tulee olla monipuolinen ja mahdollisimman realistinen. Skenaariossa on hyvä ottaa huomioon se, että myös satunnaiset toiminnot ovat tärkeitä, sillä ne saattavat laukaista tilanteita, jotka paljastavat verkkopalvelun heikoimmat lenkit kovan kuormituksen aikana.
• Kuormituksessa pyritään tunnistamaan ruuhkautumispiste, jossa suoritusteho ja vasteajat rupeavat poikkeamaan käyttäjän lineaarisen kasvun yhteydessä. Toisin sanoen palvelun maksimikäyttäjämäärä, jolloin sivusto toimii vielä suoritusteholtaan ja vasteajoiltaan moitteettomasti.
• Kuten poistumisharjoituksissakin, tilanne on hyvä simuloida läpi. Tällöin voidaan todeta, että ruuhkautumistilanne ei ole tositilanteessa vieras ja siihen ollaan mahdollisimman hyvin varauduttu.
• Jos sitten kaikesta huolimatta palveluun tulee ruuhkautumistilanne, niin kukin tietää tarkoin miten tulee toimia - ja tämä puolestaan nopeuttaa merkittävästi ongelmatilanteen ratkaisua.

Lue artikkelin ensimmäinen osa koskien verkkopalveluiden kuormittumisen mekanismeja täältä

Jos verkkopalvelusi ruuhkautumista ei ole testattu tai toivot muuten sen toimivuuteen toimintavarmuutta myös yllättävissä tilanteissa, ota meihin yhteyttä. Tehdään yhdessä digistäsi ruuhkahuiputkin ongelmitta kestävä kokonaisuus.