- Benchmark cases
- Staattiset sivugeneraattorit
- Tietokannat
- Pilvipohjaiset office-ympäristöt
- JSON-kirjastot
- Sisällönhallintajärjestelmät
- Ajoaikaisen ympäristön konfigurointi
- Konttitekniikat ja virtualisointi
- Mobiili- ja pilvilaskenta
Benchmark cases
Seuraavat luvut esittelevät mittaustietokantaan kootut kahdeksan mittauscasea. Casejen tavoitteena on muodostaa mahdollisimman monipuolinen ja vertailukelpoinen kokonaisuus ohjelmistojen energiankulutuksen arviointiin erilaisissa käyttöympäristöissä. Kukin case tarkastelee ohjelmistotekniikan osa-aluetta, jolla on joko laaja käytännön merkitys nykyaikaisissa tietojärjestelmissä tai erityinen tutkimuksellinen kiinnostavuus energiatehokkuuden näkökulmasta.
Casejen kuvauksissa käsitellään tarkasteltavan teknologia-alueen taustaa, mittauksen tavoitteita, käytettyjä tekniikoita ja mittausjärjestelyjä sekä mittauksissa tehtyjä keskeisiä havaintoja. Mittausympäristöjen suunnittelussa tavoitteena on ollut mahdollisimman hyvä toistettavuus, automatisoitavuus ja vertailukelpoisuus eri teknologioiden välillä.
Mittauscasejen alkuperäiset projektitiedostot ovat saatavilla Turun yliopiston GitLab-ympäristöstä.
Staattiset sivugeneraattorit
Sivustojen sisällönhallintaan verkossa on vakiintunut muutamia perustekniikoita. Perinteisesti yleisin lähestymistapa on ollut dynaamiseen sisällönhallintajärjestelmään ( CMS) perustuva ratkaisu, jossa sivut generoidaan palvelimella käyttäjän pyynnön yhteydessä. Viime vuosina rinnalle on kuitenkin noussut nopeasti yleistynyt staattinen sivugenerointi, jossa sivuston sisältö rakennetaan valmiiksi staattisiksi tiedostoiksi ennen julkaisua.
Staattisen sivugeneroinnin ympärille on muodostunut niin sanottu Jamstack-arkkitehtuuri ( JavaScript, API, Markup), jossa verkkosivusto koostuu valmiiksi renderöidyistä tiedostoista, selainpuolen JavaScript-toiminnallisuudesta sekä API-pohjaisista taustapalveluista. Lähestymistavan etuina pidetään erityisesti skaalautuvuutta, tietoturvaa ja suorituskykyä, koska palvelimen ei tarvitse muodostaa sisältöä jokaiselle käyttäjälle erikseen.
Staattinen sivugenerointi otettiin mukaan benchmark-tietokantaan kahdesta pääsyystä. Ensinnäkin kyseessä on nopeasti yleistyvä tapa rakentaa verkkopalveluita, jolloin eri generointitekniikoiden energiatehokkuuden vertailu on käytännöllisesti kiinnostavaa. Toiseksi staattisten sivujen energiankulutusta voidaan verrata perinteisiin sisällönhallintajärjestelmiin, jolloin voidaan arvioida arkkitehtuuristen ratkaisujen vaikutusta kokonaisenergiankulutukseen.
Mittauksissa tarkasteltiin seuraavia teknologioita:
- Gatsby
- Next.js
- Turun yliopiston oma sivugeneraattori
Valintakriteereinä olivat teknologioiden suosio, avoin lähdekoodi sekä tutkimusryhmän aiempi kokemus kyseisistä ratkaisuista. Lisäksi teknologiat edustavat hieman erilaisia toteutusmalleja staattiseen sivugenerointiin.
Navigointimittauksissa backend-palvelimena käytettiin kevyttä nginx-palvelinta ja selainautomaation toteutuksessa Seleniumia. Mittaukset suoritettiin Docker-pohjaisissa ympäristöissä, jotta mittausympäristö pysyisi mahdollisimman toistettavana ja helposti siirrettävänä eri laitteistoille.
Sisältönä käytettiin Turun yliopiston ohjelmistotekniikan ohjelmointikurssien kurssiportaalin materiaalia, joka sisältää tekstiä, ohjelmakoodia, kuvia, videoita, diaesityksiä sekä dynaamisia sisältöelementtejä. Tarkoituksena oli mallintaa realistinen moderni verkkosivusto eikä pelkästään yksinkertainen staattinen HTML-sivukokonaisuus.
Mittauksissa tarkasteltiin kahta pääkäyttötapausta:
- Käyttötapaus A: Sivuston generointi komentoriviltä Docker-kontissa
- Käyttötapaus B: Sivuston navigointi selaimella Selenium-skriptin avulla
Generointivaiheen mittauksissa tarkasteltiin erityisesti koko sivuston rakentamisen energiankulutusta, prosessointiaikaa ja resurssikuormaa. Navigointimittauksissa taas pyrittiin arvioimaan selainpuolen kuormitusta sekä palvelimen resurssikäyttäytymistä käytännön selaustilanteissa.
Mittauscasen tavoitteena oli selvittää:
- kuinka paljon eri staattiset sivugeneraattorit eroavat energiankulutukseltaan
- miten generointivaiheen kustannukset suhteutuvat sivuston käyttöön
- millaisia eroja syntyy verrattaessa staattista sivugenerointia perinteisiin CMS-ratkaisuihin
Tietokannat
Tietokannat muodostavat lähes kaikkien modernien verkkopalveluiden, liiketoimintajärjestelmien ja sovellusalustojen keskeisen taustakomponentin. Suuri osa palvelinympäristöjen työkuormasta liittyy datan tallennukseen, hakuun, indeksointiin, transaktioihin ja välimuistitoimintoihin. Tämän vuoksi tietokantajärjestelmien energiankulutuksella voi olla merkittävä vaikutus koko järjestelmän energiankäyttöön.
Relaatiotietokannat ovat edelleen yleisimpiä tietokantateknologioita, ja niiden avoimen lähdekoodin toteutuksista tunnetuimpia ovat MySQL, MariaDB ja PostgreSQL.
Tietokannat otettiin mukaan benchmark-tietokantaan, koska tietokantapalvelin on usein yksi järjestelmäarkkitehtuurin eniten resursseja kuluttavista komponenteista. Tietokantojen optimoinnilla voidaan saavuttaa huomattavia energiansäästöjä erityisesti palvelinympäristöissä, joissa työkuormat ovat jatkuvia ja datamäärät suuria.
Mittauksissa tarkasteltiin seuraavia tietokantamoottoreita:
- MySQL
- MariaDB
- PostgreSQL
Valintakriteereinä olivat avoin lähdekoodi, laaja käyttö tuotantoympäristöissä sekä teknologioiden erilaiset arkkitehtuuriset ratkaisut.
Mittausaineistona käytettiin avoimesti saatavilla olevaa IMDB:n SQL-datasettiä sekä generoituja testiaineistoja. Mittausympäristöt toteutettiin Docker-pohjaisesti ja automatisoinnissa hyödynnettiin komentoriviskriptejä sekä Selenium-automaatiota.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Tietokannan alustaminen ja täyttö generoidulla datalla
- Käyttötapaus B: Monimutkaisten kyselyjen suorittaminen selaimen ja skriptien kautta
Mittauksissa oletettiin, että merkittävin energiankulutuksen lähde liittyy monimutkaisiin tietokantakyselyihin, erityisesti suuriin haku-, lisäys- ja poistotoimintoihin. Lisäksi tarkasteltiin levyintensiivisiä toimintoja, koska tietokannat ovat usein voimakkaasti riippuvaisia levyjärjestelmän suorituskyvystä.
Mittauscasessa pyrittiin selvittämään:
- miten eri tietokantamoottorit eroavat energiankulutukseltaan
- millainen vaikutus levyoperaatioilla ja välimuisteilla on kokonaiskulutukseen
- kuinka ylläpitotoiminnot vaikuttavat energiankäyttöön
- miten levy- ja muistipohjaiset toteutukset eroavat toisistaan
Caseen liittyvä keskeinen haaste oli käyttötapausten valtava vaihtelu. Tietokantoja voidaan käyttää hyvin erilaisilla tavoilla riippuen sovellusarkkitehtuurista, datamallista ja kuormituksesta, minkä vuoksi kaikkien todellisten käyttötilanteiden mallintaminen ei ole käytännössä mahdollista.
Pilvipohjaiset office-ympäristöt
Pilvipohjaiset office-ympäristöt ovat yleistyneet merkittävästi perinteisten paikallisesti asennettujen toimisto-ohjelmistojen rinnalla. Organisaatiot hyödyntävät yhä enemmän selainpohjaisia ratkaisuja tiedostojen hallintaan, dokumenttien yhteiskäyttöön, synkronointiin ja viestintään.
Julkisten pilvipalveluiden rinnalla myös itse-isännöidyt (self-hosted) ratkaisut ovat kasvattaneet suosiotaan. Näissä ympäristöissä organisaatio hallitsee itse palvelininfrastruktuuria, datan sijaintia ja järjestelmän ylläpitoa. Samalla myös energiankulutuksen mittaaminen ja optimointi on mahdollista tehdä hallitussa ympäristössä.
Benchmark-tietokantaan valittiin kaksi avointa pilvipohjaista office-ympäristöä:
- Seafile
- Nextcloud
Valintakriteereinä olivat teknologioiden suosio, avoin lähdekoodi sekä niiden erilaiset lähestymistavat tiedostojen hallintaan ja synkronointiin. Nextcloud tarjoaa laajan kokonaisuuden yhteistyöominaisuuksia, kuten verkkotoimiston, kalenterit, chatin ja videokonferenssit, kun taas Seafile keskittyy erityisesti tehokkaaseen tiedostojen synkronointiin ja deduplikointiin.
Mittausaineistona käytettiin erilaisia toimistokäytössä tyypillisiä tiedostotyyppejä, multimediatiedostoja sekä Linux-kernelin lähdekoodia. Selainautomaatiossa käytettiin Seleniumia.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Tiedostojen lataaminen palveluun ja palvelusta
- Käyttötapaus B: Tiedostojen selaus ja esikatselu selaimessa
Mittauscasen tavoitteena oli:
- arvioida pilvipohjaisten office-ympäristöjen energiankulutusta
- tunnistaa kuormittavimmat toiminnot
- vertailla eri arkkitehtuuriratkaisujen energiatehokkuutta
- selvittää tiedostojen siirron ja synkronoinnin kustannuksia
Mittauksissa havaittiin, että tiedostojen lähettäminen palvelimelle kulutti enemmän energiaa kuin tiedostojen lataaminen palvelimelta käyttäjälle. Lisäksi Seafile osoittautui useimmissa mittauksissa energiatehokkaammaksi kuin Nextcloud, mikä liittynee sen kevyempään arkkitehtuuriin ja pienempään ominaisuuksien määrään.
JSON-kirjastot
JSON (JavaScript Object Notation) on noussut modernien verkkopalveluiden, REST-rajapintojen, mikropalveluarkkitehtuurien ja konfiguraatiotiedostojen aikakaudella yhdeksi yleisimmistä datan siirto- ja tallennusformaateista. Formaatin yksinkertaisuus, ihmisen luettavuus ja ohjelmointikieliriippumattomuus ovat johtaneet siihen, että käytännössä kaikki yleiset ohjelmointikielet tarjoavat useita vaihtoehtoisia kirjastoja JSON-datan käsittelyyn.
JSON näkyy lähes kaikkialla modernissa ohjelmistokehityksessä: selain- ja palvelinsovelluksissa, mobiiliohjelmistoissa, pilvipalveluissa, sisäisissä rajapinnoissa ja tietojärjestelmien välisessä integraatiossa. Tämän vuoksi JSON-datan käsittely muodostaa usein huomaamattoman mutta jatkuvasti toistuvan osan ohjelmistojen suorituspolkua. Vaikka yksittäinen JSON-operaatio olisi kevyt, voi niiden suuri määrä aiheuttaa merkittävää prosessori- ja muistikuormaa erityisesti suurissa palvelinjärjestelmissä.
JSON-kirjastot otettiin mukaan benchmark-tietokantaan, koska niiden energiatehokkuutta on tutkittu huomattavasti vähemmän kuin suorituskykyä. Samalla kyseessä on teknologia-alue, jossa valittujen kirjastojen ja toteutustapojen vaikutukset voivat kertautua laajamittaisessa tuotantokäytössä huomattaviksi.
Mittauscase keskittyi erityisesti Java-ekosysteemiin, jossa JSON-kirjastoja on poikkeuksellisen paljon ja niiden toteutustavoissa on merkittäviä eroja. Osa kirjastoista perustuu DOM-tyyppiseen koko dokumentin muistissa käsittelyyn, kun taas osa hyödyntää streaming-pohjaisia ratkaisuja, joissa dataa käsitellään vaiheittain ilman koko rakenteen lataamista muistiin.
Mittauksissa tarkasteltiin seuraavia tekniikoita:
- java-json-benchmark -projektin sisältämät JSON-kirjastot
- DOM-pohjaiset vs streaming-pohjaiset jäsentimet
- eri Java-virtuaalikoneiden asetukset
Valintakriteereinä olivat kirjastojen suosio, avoin lähdekoodi sekä aiempien suorituskykyvertailujen saatavuus. Olemassa olevia benchmark-toteutuksia voitiin hyödyntää energiamittausten pohjana suhteellisen pienillä muutoksilla.
Mittausjärjestely perustui valmiiseen java-json-benchmark -projektiin, joka sovitettiin toimimaan PowerGoblin-mittausjärjestelmän kanssa. Näin voitiin hyödyntää olemassa olevia suorituskykytestejä energiankulutuksen arviointiin ilman, että koko mittausympäristöä tarvitsi rakentaa alusta alkaen.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: JSON-datan jäsentäminen muistirakenteiksi
- Käyttötapaus B: JSON-datan serialisointi tekstimuotoon
- Käyttötapaus C: Streaming- ja databinding-tekniikoiden vertailu
- Käyttötapaus D: Virtuaalikoneen asetusten ja roskienkeruun vaikutusten arviointi
Mittauscasen tavoitteena oli:
- vertailla JSON-kirjastojen energiankulutusta
- selvittää suorituskyvyn ja energiankäytön välistä suhdetta
- arvioida muistinkäytön vaikutuksia energiankulutukseen
- tutkia virtuaalikoneen konfiguroinnin vaikutuksia energiatehokkuuteen
Mittauksissa havaittiin, että JSON-kirjastojen välillä voi olla huomattavia eroja energiankulutuksessa erityisesti suurilla aineistoilla ja toistuvissa operaatioissa. Erot liittyivät muun muassa muistin käyttöön, väliolioiden määrään, jäsentämisstrategiaan sekä virtuaalikoneen optimointeihin. Lisäksi streaming-pohjaiset ratkaisut osoittautuivat usein muistitehokkaammiksi kuin koko dokumentin muistissa käsittelevät ratkaisut.
Sisällönhallintajärjestelmät
Sisällönhallintajärjestelmät (Content Management System, CMS) ovat yksi yleisimmistä tavoista toteuttaa verkkosivustoja ja verkkopalveluita. Ne tarjoavat valmiin ympäristön sisällön luomiseen, hallintaan ja julkaisuun ilman, että käyttäjän tarvitsee hallita varsinaista verkkokehitystä tai palvelininfrastruktuuria.
CMS-järjestelmät ovat vuosien aikana kehittyneet laajoiksi ohjelmistoalustoiksi, joihin on saatavilla tuhansia teemoja, lisäosia ja integraatioita. Samalla niiden arkkitehtuurit ovat monimutkaistuneet ja resurssitarpeet kasvaneet. Suuri osa verkkopalveluista perustuu edelleen dynaamiseen sisällön muodostamiseen, jossa jokainen sivupyyntö aiheuttaa palvelinpuolella tietokantakyselyitä, sivupohjien renderöintiä ja lisäosien suorittamista.
Sisällönhallintajärjestelmät otettiin mukaan benchmark-tietokantaan, koska ne muodostavat merkittävän osan maailman verkkopalveluista. Energiatehokkuuden näkökulmasta kiinnostavaa on erityisesti verrata dynaamista sisällönhallintaa staattiseen sivugenerointiin sekä arvioida, miten järjestelmän ominaisuuksien määrä vaikuttaa energiankulutukseen.
Mittauksissa tarkasteltiin seuraavia tekniikoita:
- WordPress
- MySQL/MariaDB
- nginx
- WordPressin plugin-ekosysteemi
Valintakriteereinä olivat WordPressin erittäin laaja käyttö, avoin lähdekoodi sekä tutkimusryhmän aiempi kokemus järjestelmästä. WordPress toimii myös hyvänä esimerkkinä modernista laajennettavasta CMS-arkkitehtuurista.
Mittausympäristössä sivuston sisältö generoitiin automaattisesti sisältögeneraattoripluginilla, joka tuotti realistista sisältöä sisältäen tekstiä, kuvia ja muita mediaelementtejä. Tavoitteena oli mallintaa aidon verkkopalvelun toimintaa eikä pelkästään yksinkertaista testisivua.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Sisällön generointi ja editointi
- Käyttötapaus B: Sivuston navigointi selaimella Selenium-skriptillä
- Käyttötapaus C: Sivuston varmuuskopiointi ja palauttaminen
Mittauscasen tavoitteena oli:
- arvioida CMS-järjestelmien energiankulutusta
- vertailla dynaamista ja staattista sisällöntuotantoa
- tunnistaa järjestelmän kuormittavimmat osat
- arvioida tietokannan ja lisäosien vaikutuksia kokonaiskulutukseen
Mittauksissa havaittiin, että dynaaminen sisällöntuotanto aiheuttaa merkittävästi enemmän palvelinkuormaa kuin staattinen sivugenerointi. Erityisesti tietokantakyselyiden määrä, plugin-ekosysteemin laajuus ja palvelinpuolen renderöinti vaikuttivat energiankulutukseen. Lisäksi havaittiin, että välimuistiratkaisujen käyttö voi vähentää energiankulutusta huomattavasti paljon liikennöidyissä sivustoissa.
Ajoaikaisen ympäristön konfigurointi
Ohjelmiston energiankulutukseen vaikuttaa itse ohjelmakoodin lisäksi myös se, millaisessa ajoaikaisessa ympäristössä ohjelmaa suoritetaan. Erityisesti virtuaalikoneisiin ja dynaamisiin optimointeihin perustuvissa ohjelmointiympäristöissä ajoaikainen konfigurointi voi vaikuttaa merkittävästi suorituskykyyn, muistinkäyttöön ja energiankulutukseen.
Modernit ohjelmointikielet hyödyntävät usein erilaisia optimointitekniikoita, kuten Just-in-Time (JIT) -käännöstä, Ahead-of-Time (AOT) -käännöstä sekä automaattista roskienkeruuta. Nämä voivat parantaa suorituskykyä pitkissä ajoissa, mutta samalla ne saattavat kasvattaa käynnistysvaiheen kustannuksia tai aiheuttaa ylimääräistä prosessorikuormaa.
Ajoaikaisen ympäristön konfigurointi otettiin mukaan benchmark-tietokantaan, koska ohjelmistokehityksessä tehdään jatkuvasti valintoja ajoaikaisista asetuksista, mutta niiden energiatehokkuutta arvioidaan harvoin systemaattisesti.
Mittauksissa tarkasteltiin seuraavia tekniikoita:
- Just-in-Time (JIT) -käännös
- Ahead-of-Time (AOT) -käännös
- GraalVM native-image
- erilaiset roskienkeruualgoritmit
- Java-virtuaalikoneen optimointiasetukset
Mittausjärjestelyssä sama ohjelma suoritettiin useilla eri ajoaikaisilla asetuksilla ja käännöstavoilla. Erityistä huomiota kiinnitettiin kylmäkäynnistystilanteisiin, joissa ohjelma käynnistetään ilman aiempaa välimuistia tai valmiiksi optimoitua tilaa.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Sovelluksen käynnistäminen eri käännöstavoilla
- Käyttötapaus B: Roskienkeruun vaikutusten mittaaminen
- Käyttötapaus C: Native-image- ja virtuaalikoneajon vertailu
- Käyttötapaus D: Virtuaalikoneen optimointiasetusten vaikutusten arviointi
Mittauscasen tavoitteena oli:
- arvioida ajoaikaisen ympäristön vaikutuksia energiankulutukseen
- vertailla JIT- ja AOT-lähestymistapoja
- selvittää roskienkeruun energiakustannuksia
- tutkia käynnistysajan ja energiankulutuksen välistä suhdetta
Mittauksissa havaittiin, että JIT- ja AOT-tekniikoiden välillä ei ollut suuria eroja pitkäkestoisissa ajoissa, mutta kylmäkäynnistystilanteissa erot korostuivat. GraalVM native-image suoriutui tehtävistä huomattavasti nopeammin ja pienemmällä energiankulutuksella erityisesti lyhyissä suorituksissa. Roskienkeruualgoritmien välillä havaittiin eroja erityisesti muistinkäytön ja suorituspiikkien yhteydessä.
Konttitekniikat ja virtualisointi
Konttiteknologiat ja virtualisointi ovat muodostuneet keskeiseksi osaksi modernia palvelininfrastruktuuria ja pilvilaskentaa. Niiden avulla sovelluksia voidaan eristää, siirtää ja hallita tehokkaasti erilaisissa ympäristöissä. Samalla abstrahointikerrokset aiheuttavat lisäkustannuksia suorituskyvyn, resurssien käytön ja energiankulutuksen näkökulmasta.
Perinteinen virtualisointi perustuu kokonaisen käyttöjärjestelmän ajamiseen virtuaalikoneessa, kun taas konttiteknologiat hyödyntävät käyttöjärjestelmän yhteisiä resursseja ilman täyttä laitteistovirtualisointia. Tämän vuoksi konttien oletetaan olevan kevyempiä ja energiatehokkaampia kuin virtuaalikoneiden.
Konttitekniikat ja virtualisointi otettiin mukaan benchmark-tietokantaan, koska ne muodostavat perustan monille moderneille DevOps-, pilvi- ja mikropalveluympäristöille. Samalla niiden energiavaikutuksia tunnetaan vielä verrattain huonosti.
Mittauksissa tarkasteltiin seuraavia tekniikoita:
- Docker vs systemd-nspawn vs QEMU/KVM
- Linuxin namespace- ja cgroup-teknologiat
- Ajonaikaisen ympäristön konfigurointi
Valintakriteereinä olivat teknologioiden yleisyys, avoin lähdekoodi sekä niiden erilaiset toteutustavat eristyksen ja resurssienhallinnan suhteen.
Työkuormana käytettiin Linux-kernelin lähdekoodin pakkaamista, koska se muodostaa realistisen ja helposti toistettavan prosessori- ja levyintensiivisen tehtävän. Sekä laskenta että levyoperaatiot ovat perinteisesti muodostaneet haasteita virtualisoiduille ympäristöille. Lisäksi tehtävässä korostuu toiminnan käynnistämisen ja lopettamisen tuoma lisäkuorma, mikä on oleellista varsinkin lambda-tyyppisten lyhytaikaisten palveluiden tapauksessa.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Pakkaustehtävän suoritus Docker-tekniikalla
- Käyttötapaus B: Pakkaustehtävän suoritus nspawn-tekniikalla
- Käyttötapaus C: Pakkaustehtävän suoritus KVM-virtuaalikoneessa
Mittauscasen tavoitteena oli:
- vertailla konttien ja virtualisoinnin energiankulutusta
- arvioida eristystekniikoiden suorituskykykustannuksia
- tutkia käynnistysvaiheen vaikutuksia kokonaiskulutukseen
- selvittää kuinka paljon abstrahointikerrokset vaikuttavat energiatehokkuuteen
Mittauksissa havaittiin, että Docker ja systemd-nspawn olivat energiatehokkaampia kuin virtuaalikoneet. systemd-nspawn saavutti parhaat tulokset sekä käynnistysajassa että työkuorman suorittamisessa. Virtuaalikoneiden energiankulutusta kasvatti erityisesti laitteistovirtualisoinnin aiheuttama ylimääräinen resurssikuorma.
Mobiili- ja pilvilaskenta
Mobiililaitteiden suorituskyky on kasvanut voimakkaasti viime vuosina, mutta samalla myös kysymys laskennan sijoittamisesta päätelaitteelle tai pilvipalveluun on noussut keskeiseksi ohjelmistokehityksen suunnittelukysymykseksi. Erityisesti laskennallisesti raskaat sovellukset, kuten pelit, multimedia ja tekoälysovellukset, voivat joko hyödyntää paikallista suorituskykyä tai siirtää kuormaa palvelinympäristöihin.
Pilvilaskenta mahdollistaa raskaan laskennan suorittamisen tehokkailla palvelimilla, mutta samalla tiedonsiirto ja verkkoviiveet aiheuttavat omia energiakustannuksiaan. Toisaalta mobiililaitteiden rajallinen suorituskyky ja akkukapasiteetti tekevät energiatehokkuudesta erityisen tärkeän näkökulman.
Mobiili- ja pilvilaskenta otettiin mukaan benchmark-tietokantaan, koska se mahdollistaa eri suoritusympäristöjen ja ohjelmakoodin toteutustapojen vertaamisen käytännön työkuormalla.
Mittauksissa tarkasteltiin seuraavia tekniikoita:
Natiivikoodi vs WebAssembly: Mittaustapauksen lähtökohtana oli laskentaintensiivinen natiivilla binäärikoodilla tuotettu ohjelma. Tällaisen ohjelman tapauksessa hyvin todennäköinen modernisointi on ohjelman käännös WebAssembly-koodiksi selainympäristöön. Muunnoksen energiatehokkuutta voidaan arvioida vertaamalla käännöstä alkuperäiseen.
Mobiililaite (tabletti, puhelin) vs palvelinympäristö: Edellä kuvattua WebAssembly-koodia voidaan suorittaa palvelin- ja työpöytälaitteiden lisäksi mobiililaitteella. Nykyään ohjelmistojen arkkitehtuuri voi olla monin tavoin hajautettu ja on oleellista tietää, mitkä osat laskennasta on edullista tehdä milläkin laitetyypillä.
Mittausjärjestelyssä käytettiin Doom-pelin timedemo-toimintoa, jonka avulla voitiin suorittaa identtinen ja deterministinen työkuorma eri ympäristöissä. Vertailussa olivat palvelintietokone, tabletti ja älypuhelin. Pelin laskenta on CPU-painotteista ja timedemo-ominaisuus poistaa suoritusnopeuden rajoittimen, joten mittaus korostaa laskennan osuutta.
Mittauksissa tarkasteltiin seuraavia käyttötapauksia:
- Käyttötapaus A: Natiivin pelin suoritus palvelimella
- Käyttötapaus B: WebAssembly-version suoritus palvelimella
- Käyttötapaus C: WebAssembly-version suoritus mobiililaitteella
Mittauscasen tavoitteena oli:
- vertailla mobiili- ja palvelinlaskennan energiankulutusta
- selvittää suoritusympäristön vaikutuksia energiankäyttöön
- tutkia hajautetun laskennan sijoittamisen vaikutuksia kokonaiskulutukseen
Mittauksissa havaittiin, että natiiviversio suoritti työkuorman nopeimmin ja pienimmällä energiankulutuksella. WebAssembly-versiot olivat hitaampia ja kuluttivat enemmän energiaa erityisesti mobiililaitteilla. Mobiililaitteiden rajallinen suorituskyky korosti suoritusajan vaikutusta kokonaisenergiankulutukseen. Tämä mittaustyyppi on erityisen hyödyllinen kun suunnitellaan monipaikkaisen ohjelmiston laskennan sijoittamista hajautetussa ympäristössä.