Alhainen latenssi luo laatua myös palveluissa



Latenssin mittaus ei ole vain kauniita palloja, se on vakavaa tiedettä. Kuva: Kyle Hailey

Vanha vitsi sanoo, että ensimmäisessä työpaikassa vaikuttaa fiksummalta kun onkaan, kun vain kysyy, miten voisimme lyhentää prosessin läpimenoaikaa. Mutta vitsi ei olisi hauska, jos siinä ei olisi ripausta totta.

Latenssi käännetään yleensä vasteajaksi, ja se on oleellinen käsite kun puhutaan siitä, miltä ohjelmisto tuntuu käyttäjälle.  Jokainen meistä on kokenut esimerkiksi hitaan verkkosivun: jos verkkosivu latautuu hitaasti, käyttäjä tuskastuu ja poistuu, ja yritys on juuri menettänyt potentiaalisen asiakkaan. Googlen suositusten mukaan verkkosivun olisi latauduttava kahdessa sekunnissa, ja Amazonin tutkimus vuodelta 2008 kertoo, että jokainen 100ms:n – siis sekunnin kymmenesosan – lisäys verkkosivun latautumiseen pudotti kävijämäärää 1%:lla. Aika on rahaa, mutta Amazonilla millisekunnit ovat miljoonia.

Eritoten mobiiliverkkosivuilla vasteajan optimointi korostuu, koska tyypillinen mobiiliverkko lisää kymmeniä, ellei satoja millisekunteja ylimääräistä jokaiseen uuteen selaimen tekemään verkkoyhteyteen.  Yksi iso syy mobiiliapplikaatioiden suosioon onkin se, että käyttäjän kokemus on helpompi optimoida, kun kaikki hitaasti latautuvat elementit (esim. kuvat ja muut mediatiedostot) on jo asennettu puhelimeen, ja varsinainen verkkoyhteys voidaan suorittaa taustalla. Lopputulos sekä tuntuu nopeammalta, että näyttää paremmalta.

Ennen vanhaan palvelimen hajoaminen tarkoitti uuden fyysisen palvelimen tilaamista, ja pahimmassa tapauksessa viikkojen – parhaimmassakin tapauksessa tuntien odottelua, että uusi palvelin saatiin tilattua, asennettua ja konfiguroitua tuottavaan työhön. Eräs tärkeä syy siihen, että pilvipalvelut ovat ottaneet niin vahvasti tuulta alleen on se, että nyt palvelimen vaihtaminen kestää minuutteja – ja jos hitaan ihmisen ottaa välistä kirjoittamasta komentoja, ehkä vain joitain kymmeniä sekunteja.  Kuten ekonomi sanoisi, prosessin läpimenoaika on optimoitu.

Mutta tämähän on vain koodausta?

Kun puhutaan ohjelmistoarkkitehtuurin suorituskyvystä, tarkoitetaan kahta asiaa: kuinka monta toimintoa järjestelmä pystyy suorittamaan sekunnissa, ja kuinka kauan yksittäinen toiminto kestää.  Nämä eivät ole täysin toisistaan riippumattomia – jos verkkopalvelussa pystytään palvelemaan yksi pyyntö sadassa millisekunnissa, jolloin yksi CPU pystyy vastaamaan 10 pyyntöön sekunnissa. Jos latenssi puolitetaan 50 ms:iin, yksi CPU pystyy vastaamaan 20 pyyntöön sekunnissa, jolloin palvelu tarvitsee vain puolet keskusyksiköiden määrästä, mikä puolestaan on suoraa rahansäästöä.

Vaikka on siis tärkeää rakentaa skaalautuvaksi tarkoitettu järjestelmä sellaiseksi, että siihen voi tarvittaessa vain lisätä uusia koneita, käyttäjälle näkyvä suorituskyky on usein kiinni puhtaasti järjestelmän latensseista.  Näitä syntyy järjestelmässä monissa kohtaa, ja vaikka alla olisi kuinka modernit teknologiat, huonoa arkkitehtuuria voi olla silti vaikea skaalata. Latenssia voi olla missä tahansa kohtaa järjestelmässä DNS-kyselyistä tietokantakoneen levyaccessiin asti, ja satunnaisiin paikkoihin välimuistien lisääminen voi jopa huonontaa tilannetta. Periaatteessa hyvässäkin arkkitehtuurissa voi syntyä pullonkauloja yllättäviin paikkoihin, sillä tuotantoliikenne ei yleensä ole aivan sellaista, mitä on suunniteltu. Siksi esim. profilointi ja oikeanlainen logittaminen ovat ensiarvoisia työkaluja myös tuotantojärjestelmissä.

(Sivuhuomiona sanottakoon, että IT-arkkitehdin työ on yksi niitä maailman harvoja töitä, jossa valon nopeus on todella työtä rajoittava asia: bitti ei yksinkertaisesti voi liikkua Singaporesta Suomeen nopeammin kuin 31 millisekunnissa, ellei joku keksi keinoa suihkuttaa neutriinoja suoraan pallon läpi.)

Latenssi asuu rosessissa

Yksi syy siihen, miksi ketterät menetelmät (engl. agile) on otettu nykyään käyttöön on se, että se parantaa tiimin kykyä reagoida muutoksiin – siis pienentää tiimin latenssia. Liiketoimintaympäristön tai spesifikaation muuttuessa ei ole varaa palata takaisin piirustuspöydälle rakentamaan kaikkea alusta, vaan lyhyillä iteraatioilla pyritään pitämään tiimin kyky ohjata itseään oikeaan suuntaan mahdollisimman nopeana.

Ketterien menetelmien tavoite on lyhentää tämän kierron kestoa.
Ketterien menetelmien tavoite on lyhentää tämän kierron kestoa.

Perinteinen tapa kuvata asiaa on kuvassa oleva prosessipyörä. Näitä pyöriä on monenlaisia, mutta ketterien menetelmien perusperiaate on se, että yhtä ympyrän kierrosta – siis läpimenoaikaa – yritetään nopeuttaa mahdollisimman paljon.  Toimiva, ketterä tiimi pystyy viemään tuotantoon uusia ohjelmistoversioita 15-20 kertaa vuorokaudessa kuitenkaan riskeeraamatta järjestelmän toimintaa.  Tämä tarkoittaa sitä, että esimerkiksi ohjelmistovirheisiin voidaan reagoida erittäin nopeasti, jolloin tuottava työaika kohdistuu varsinaiseen tekemiseen, eikä niinkään odotteluun.

Koskee kaikkia koko firmassa

Olisi kuitenkin tyhmää ajatella vasteaikaa vain designerien ja nörttien valtakuntaan kuuluvana asiana. Asiakkaalle kaikenlainen yhteistyö yrityksesi kanssa koostuu latenssista: Palvelusi on oltava helppo ja nopea löytää (harrasta hakukoneoptimointia), verkkosivujen on latauduttava nopeasti (se nörttiosuus), niiden on selkeästi ja välittömästi kerrottava, miksi juuri täältä pitäisi ostaa ja mitä sieltä saa (se designer-osuus), kysymyksiä pitää olla helppo esittää ja niihin pitää saada nopeasti vastaus, oston ja tuotteen käytönoton pitää olla nopeaa ja sujuvaa – ja jopa tuotteen käytön lopettamisen pitää olla helppoa.

Asiakkaallasi on parempaakin tekemistä kuin ihmetellä. Peliteollisuus on ymmärtänyt tämän: käyttäjä on saatava koukkuun ensi hetkestä alkaen, koska verkkokaupasta saa miljoona muutakin peliä, jos tämä peli ei heti aukene. Jos jotain pelimaailmasta tulisi siirtää B2B tai B2C-puolelle, niin tämä.

Piilaaksossa on kirjoittamaton sääntö, jonka mukaan jokaiseen sähköpostiin tai muuhun yhteydenottoon on vastattava alle 24 tunnissa. Useimmat vastaavat sitä nopeammin, myös viikonloppuisin.  Harva asia tekee asiakkaan olon yhtä ei-toivotuksi kuin hidas vasteaika, ja nopea vastaaja usein saa myös asiakkuuden.  Tässä olisi monella firmalla parannettavaa.

Asiakkaan kannalta pieni latenssi on laatua.

Lisätietoa verkkosivujen optimoinnista

Steve Souders: High Performance Websites

Tämän artikkelin on kirjoittanut Janne Jalkanen  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *