Kopioi artikkelin PDF-versio
Suorituskyky on usein ehdoton vaatimus. Ohjelmisto on arvoton, mikäli se ei selviä kuormastaan käytettävissä olevin resurssein. Perinteisesti teho-ongelmat on ratkottu, kun ne on havaittu eli projektin lopussa. Kehitettäessä suuria ja reaaliaikaisia ohjelmistoja tämä voi johtaa kalliisiin ja hankaliin muutoksiin.
Ohjelmiston suorituskyvyn ajatellaan usein tarkoittavan vain nopeutta, mutta laajemmin ajateltuna se on ohjelmiston kykyä selviytyä sille kuuluvista tehtävistä käytettävissä olevilla resursseilla. Suorituskykyä on siis monenlaista: usein tärkeää on vasteaika, toisinaan taas läpimenonopeus tai laskennan vaatima tila.
Ohjelmiston elinkaaren kannalta tärkeitä ovat suorituskyvyn skaalautuvuus ja tasapaino. Skaalautuvan ohjelmiston ominaisuudet säilyvät sen ympäristön muuttuessa; suorituskyky kasvaa suhteessa laitteiston tehoon. Tasapaino taas tarkoittaa sitä, että ohjelmiston eri komponentit ovat sopusoinnussa keskenään ja käyttävät tasaisesti laitteistoresursseja.
Suorituskyky on kompromissi erilaisten tavoitteiden välillä. Usein muut vaatimukset kuten toiminnallisuus, oikeellisuus ja käytettävyys ovat osittain ristiriidassa suorituskyvyn kanssa. Lisäksi suorituskykytavoitteet sinällään voivat olla ristiriitaisia. Esimerkiksi hyvän vasteajan vuoksi ohjelmisto rakennetaan reaktiiviseksi; läpimenonopeuden kannalta tällainen ratkaisu ei ole hyvä.
Parhaan mahdollisen suorituskyvyn tavoittelu on lähes poikkeuksetta liian kallista. Yleensä kannattaa tietoisesti pyrkiä vain kohtuulliseen suorituskykyyn, jolloin muiden tavoitteiden saavuttaminen helpottuu ja ohjelmistokehityksen kustannukset pysyvät kurissa.
Sudenkuoppia riittää
Jos ohjelmiston perusasiat eivät ole kunnossa, sen suorituskyky voi käyttäytyä yllättävästi. Yleensä ohjelmisto toimii sitä nopeammin mitä tehokkaampi laitteisto on käytössä. Tämä ei välttämättä päde, jos ohjelmiston suorituskyky ei ole skaalautuva. Esimerkiksi fysikaalisista lainalaisuuksista aiheutuvat tietoliikenneviiveet saattavat rajata suorituskyvyn niin, ettei ohjelmistoa saada olennaisesti nopeutettua millään laitteistolla.
Vastaavan kaltaisia ikäviä yllätyksiä voi tuottaa suorituskyvyn epätasapaino. Tällöin esimerkiksi ohjelmiston jonkin komponentin suorituskyvyn parantaminen saattaa pudottaa dramaattisesti ohjelmiston kokonaissuorituskykyä. Tällainen tilanne johtuu usein siitä, että järjestelmässä on pullonkaula, joka tukkeutuu entistä pahemmin, kun nopeus sen ympärillä kasvaa.
Algoritmeihin liittyvät kompleksisuusmitat ovat usein harhaanjohtavia. Nykyisissä konearkkitehtuureissa muistinkäytön määrä ja paikallisuus ovat usein ratkaisevampia kuin algoritmin vaatima askelmäärä. Algoritmikirjallisuuden mukainen nopea algoritmi saattaakin olla haluttuun käyttötarkoitukseen toivottoman hidas.
Suorituskyvyn voi suunnitella
Ohjelmistojen suunnittelussa keskitytään yleensä toiminnallisten vaatimusten toteuttamiseen. Ohjelmistojen kehitysprosesseissa muut vaatimukset, kuten suorituskyky, jäävät taka-alalle. Tällöin suorituskykyongelmia joudutaan korjailemaan jälkeenpäin niiden tullessa esille lopputestauksen yhteydessä.
Ohjelmiston kehityksessä unohtuu helposti se, että ohjelmiston suorituskyvyn voi suunnitella siinä missä toiminnallisuudenkin. Tärkeää on, että suorituskykytavoitteet ja niihin liittyvät toteutusongelmat tiedostetaan mahdollisimman aikaisin.
Ohjelmistokehityksen tavoitteet kannattaa harkita tarkkaan. On hyvä huomata, että markkinointi on usein helpoin tapa ratkaista suorituskykyongelmia kun etukäteen tiedetään syntyvän ohjelmiston heikkoudet, niin sitä ei myydä tarkoituksiin, joissa se ei menesty.
Ohjelmiston kehityskaaren alussa sen tulevaa suorituskykyä ei tarkasti pystytä ennustamaan, mutta likimääräiset ennusteet yleensä riittävät tarvittavien päätösten tekoon. Tällöin tärkeää ei ole valita erilaisista teknisistä ratkaisuista parasta, vaan sulkea pois ne vaihtoehdot, jotka eivät voi tuottaa riittävää suorituskykyä.
Kun ohjelmiston yleisrakenne ja tuleva kokonaissuorituskyky tiedetään likimäärin, samankaltainen suunnittelu voidaan tehdä ohjelmiston osille. Samalla saadaan käsitys ohjelmiston laitteistovaatimuksista ja pystytään jakamaan laitteiston tarjoamat resurssit tasapainoisesti ohjelmiston osille. Näin suorituskykyongelmia ei pelkästään pystytä tunnistamaan jo varhaisessa suunnitteluvaiheessa, vaan suunnitellun suorituskyvyn toteutumista voidaan seurata jatkuvasti ohjelmiston toteutuksen edistyessä.
Mallit suunnittelun apuväline
Ohjelmistojen suorituskyvyn suunnittelu perustuu yleensä mallintamiseen. Koska ohjelmistolle yksinään ei voida laskea suorituskykyä, täytyy ohjelmiston lisäksi mallintaa ohjelmiston kuorma ja suoritusympäristö.
Ohjelmiston kuormamalli kuvaa, miten ohjelmisto saa syötteensä ja millaisia nuo syötteet ovat. Yksinkertainen esimerkki kuormamallista on luettelo syötteistä ja niiden esiintymistodennäköisyyksistä. Hyvä kuormamalli sisältää vain ne syötteen parametrit, joilla on suorituskyvyn kannalta merkitystä. Kuormamallia laadittaessa tulee siis ottaa huomioon ohjelmiston toteutusvaihtoehdot. Muutoin mallista tulee helposti niin monimutkainen, ettei ohjelmiston suorituskyky ole sen perusteella suunniteltavissa tai testattavissa, koska kaikkia parametriyhdistelmiä ei pystytä tutkimaan.
Suoritusympäristön malli kuvaa sen laitteiston ja varusohjelmiston, jota ohjelmisto käyttää. Malli on yleensä ohjelmistokohtainen, koska siitä kannattaa mallintaa vain ne asiat, jotka ovat kyseisen ohjelmiston kannalta merkittäviä. Suoritusympäristön mallintamisessa pätevät samat periaatteet kuin syötemallinnuksessa.
Ohjelmistomalli kuvaa sen, kuinka kukin ohjelmiston syöte vaatii sen suoritusympäristöltä resursseja. Tällaisia ovat esimerkiksi CPU-aika, haut massamuistista ja prosessien väliset interaktiot. Ohjelmistomalli perustuu yleensä ohjelmiston suoritusrakenteeseen, kuten prosesseihin ja niiden väliseen kommunikaatioon.
Mallinnustekniikoita on paljon. Joillain tekniikoilla voi mallintaa vain ohjelmistoa ja toisilla vain syötettä. Jotkut tekniikat taas sopivat tietyissä tilanteissa niin syötteen, ohjelmiston kuin suoritusympäristön mallintamiseen.
Mikään tekniikoista ei ole kaikenkattava. Valinnassa nyrkkisääntönä on se, että tekniikan on vastattava ominaisuuksiltaan mallinnuksen kohdetta. Jonoverkoilla ei esimerkiksi ole perusteltua mallintaa järjestelmää, jossa resursseja ei jonoteta.
Koetellut konstit kannattavat
Ohjelmistojen tekemisessä kannattaa käyttää koeteltuja ja monissa yhteyksissä hyväksi todettuja toteutustekniikoita. Valitettavan usein suunnitteluongelmia ratkotaan omaperäisesti huonolla menestyksellä, vaikka toimiva perusratkaisu olisi ohjelmistoalan kirjallisuudesta löydettävissä. Rakenteellisesti huonoihin ratkaisuihin tyypillisesti syynä lienee se, että ohjelmiston suunnitteluvaiheessa sen komponenttien luonnetta ei ymmärretä oikein.
Todelliset suorituskykyongelmat ovat usein ohjelmiston perusrakenteeseen liittyviä ongelmia. Niiden korjailu jälkikäteen on erittäin vaikeaa ilman, että merkittävä osa ohjelmistosta suunnitellaan ja toteutetaan uudestaan paremmalla tavalla.
Aiheesta enemmän
PET-projekti: http://pet.cs.hut.fi/
George Mason University: www.cs.gmu.edu/faculty/menasce.html
Carleton University: www.sce.carleton.ca/faculty/woodside.html
Computer Measurement Group: http://www.cmg.org
Institute for Computer Capacity Management: http://www.iccmforum.com
Software performance engineering is a method for constructing software systems to meet their performance requirements. For software systems, performance requirements are often mandatory a software system is worthless, if it cannot handle its workload, even if it is functionally perfect.
Performance engineering is needed instead of trying to fix the performance problems as they arise. Such late-fixes can cost significantly more than the planning. Using performance engineering methods, the performance of a software system can be planned, and the plans realized.
Performance engineering must begin early in the software development to identify satisfactory designs and to eliminate those that are likely to have an unacceptable performance. Performance engineering continues to predict and manage the performance of the evolving software through the various stages of the software life time.
Performance engineering is often based on modeling the software, its workload, and its execution environment. The research at HUT Laboratory of Information Processing Sciences has studied graph-based modeling mechanisms and their use in software engineering processes. We have focused especially on dynamic load situations of telecommunication software.
Our research project is a part of the ETX research program of the National Technology Agency of Finland. The research team is lead by professor Eljas Soisalon-Soininen(Eljas.Soisalon-Soininen@hut.fi).
Mallinnustekniikoita on paljon. Ne poikkeavat luonteeltaan merkittävästi toisistaan. Tärkeää on valita tekniikka mallinnuksen kohteen ja analyysitarpeen mukaisesti.
Jonoverkot
Laitteistoja ja niitä lähellä olevia ohjelmistoja kuvataan yleisesti jonoverkoilla. Ne soveltuvat sellaisten tilanteiden kuvaamiseen, joissa synkronointi laitteistossa ja käyttöjärjestelmässä on yksinkertaista odottamista.
Petri-verkot
Monimutkaista synkronointia, kuten tietoliikenneprotokollia, ei kannattaa kuvata jonoverkoilla, vaan esimerkiksi Petri-verkoilla. Niissä mallintaminen perustuu ehtojen ja niitä vastaavien tapahtumien kytkemiseen.
Ohjelmien mallinnus
Jono- ja Petri-verkoilla mallinnetaan yleensä resursseja ja niiden käytön välistä synkronointia. Tällainen mallinnus sopii huonosti ohjelmiin, koska suorituksen vuon ymmärtäminen on niissä keskeistä ja synkronointipisteet ovat usein kätkössä.
Suoritusverkot
Suoritusrakenteeseen pohjautuvat mallit ovat ohjelmistojen kuvaamisessa yleisiä. Tällaisia ovat esimerkiksi suoritusverkot. Ne esittävät, kuinka suoritus etenee ohjelmistossa. Suoritusverkot muistuttavat vuokaavioita, mutta ovat abstraktimpia.
Viestikaaviot
Suoritusverkot sopivat hyvin laskentakeskeisten ohjelmistojen kuvaukseen, mutta kommunikaatiota niillä on hankala kuvata. Viestikaaviot kuvaavat kommunikoivat osapuolet ja niiden väliset viestinvaihdot.