Kuopio. Raportti Rasitustestaus

Transkriptio

1 Kuopio Raportti Rasitustestaus

2 Kuopio, Rasitustestausraportti, Versiohistoria: Versio Pvm Laatija Muutokset Matti Peltomäki Ensimmäinen versio Matti Peltomäki Sisäisen katselmoinnin korjaukset Matti Peltomäki Asiakaskatselmoinnin korjaukset

3 1. JOHDANTO MENETELMÄT JA TAVOITTEET YLEISTÄ SUUNNITTELUSTA TURVALLISUUSNÄKÖKOHTIA TIEDONSIIRTOAIKA YHTEYKSIEN FUNKTIONA PYYNNÖN JONOTUSAIKA YHTEYKSIEN FUNKTIONA PUUTTEITA TOTEUTUKSEN KULKU TULOSTEN ANALYSOINTIA TIEDONSIIRTOAIKA YHTEYKSIEN FUNKTIONA PYYNTÖJEN JONOSTUSAIKA YHTEYKSIEN FUNKTIONA HAVAINTOJA HÄIRIÖTEKIJÖISTÄ...8

4 1. Johdanto Tämä dokumentti raportoi Kuopio-projektissa suoritetun järjestelmän rasitustestauksen. Dokumentti on tarkoitettu ensisijaisesti projektiryhmälle ja asiakkaalle. Kurssin henkilökunta käyttää dokumenttia kurssiarvostelua varten. Tässä raportissa esitellään kertauksenomaisesti rasitustestauksessa käytetyt menetelmät ja tavoitteet T2-vaiheessa tehtyjen suunnitelmien pohjalta. Suunnitelmissa avoimeksi jätetyt detaljit päivitetään tässä vastaamaan todellisuutta. Lisäksi esitellään lyhyesti testauksen kulku, toteutunut aikataulu ja testausta vaikeuttaneet käytännön tekijät. Viimeisessä luvussa analysoidaan rasitustestauksen tulokset ja pohditaan niiden luotettavuutta. Lisäksi esitetään parannusehdotuksia liittyen edellisessä luvussa kuvattuihin testausta vaikuttaneisiin käytännön asioihin. 2. Menetelmät ja tavoitteet 2.1. Yleistä CenterTest.NET on Microsoftin integroidun kehitysympäristön Visual Studion.NETversion osa. CenterTest on suunniteltu erityisesti www-sivustojen testaukseen. Se on yhteensopiva virtuaalisesti minkä tahansa www-palvelinohjelmiston kanssa, mutta se on suunniteltu erityisesti ASP.NET sovelluksia silmälläpitäen. CenterTest on Kuopio-projektissa kokeiltu testauksen apumenetelmä. Ennen projektia se oli projektiryhmälle aidosti uusi, mutta projektin aikana kaksi ryhmän jäsentä tutustui siihen huolellisesti. Projektissa CenterTestin ominaisuuksista käytettiin mahdollisuutta sivustojen rasitustesteihin, joita CenterTestiin voi ohjelmoida httppyyntökohtaisesti. Muita CenterTestin ominaisuuksia ei resurssipuutteen vuoksi voida ohjelmatyöprojektissa kokeilla Suunnittelusta Testausvastaava tutustui T2-vaiheen aikana huolellisesti ja kattavasti CenterTestin mahdollisuuksiin ja ominaisuuksiin. CenterTestin käyttö suunniteltiin alustavasti myös vaiheessa T2, mutta suunniteltua tarkennettiin radikaalisti LU-vaiheessa Turvallisuusnäkökohtia CenterTestin rasitustestien tarkoituksena on aiheuttaa keinotekoisesti wwwpalvelimelle määrätyn suuruista kuormaa ja samalla tarkkailla yhdeltä tai usealta työasemalta käsin verkon ja palvelimen kuormitusta. Tällainen kuormitus rasittaa suuresti verkkoa, jossa testaus tapahtuu. Tämän vuoksi rasitustestit tehdään sellaiseen vuorokaudenaikaan, jolloin muu liikenne Innofactorin sisäisessä verkossa on pienimmillään. Näin pyritään varmistamaan, että rasitustestit eivät aiheuta huomattavaa haittaa muulle liiketoiminnan kannalta oleelliselle tietoliikenteelle Tiedonsiirtoaika yhteyksien funktiona LU-vaiheessa tarkennettujen suunnitelmien mukaan ensimmäinen rasituksesta tutkittava asia on tiedon siirtämiseen kuluva aika yhteyksien funktiona. Tässä

5 yhteydessä tiedon siirtämisellä tarkoitetaan pyynnön lähettämisestä joko ensimmäisen tavun perille saapumiseen tarvittavaa aikaa (TTFB = Time To First Byte) tai vastaavaa aikaa laskettuna viimeiseen tavuun asti (TTLB = Time To Last Byte). Testaus suoritettiin useana peräkkäisenä CenterTestin testinä, jossa vaihdellaan yhtäaikaisten yhteyksien määrää esimerkiksi geometrisen jonon 1,2,4,8, mukaisesti. Tuloksista piirrettiin muutama graafi CenterTestin monipuolisten visualisointitoimintojen avulla. Graafit on esitetty luvussa Pyynnön jonotusaika yhteyksien funktiona Aiemmin todettiin, että suorituskykyä tarkkailevia apuohjelmia voidaan rasitustestauksen aikana ajaa useammalla samassa verkossa olevalla työasemalla. Tämän kohdan kuvaama menetelmä käyttää hyväkseen tätä seikkaa. Microsoftin Internet Information Services www-palvelinohjelmisto pitää sisällään mainiosti hyödylliseen testaukseen soveltuvia suorituskykyä tarkkailevia apuohjelmia. LU-vaiheessa tarkennettiin rasitustestauksen suunnitelmia, ja tutustuttiin huolellisesti näihin toimintoihin. Toimintojen valtavan kirjon vuoksi ei läheskään kaikkia hyödylliseksi perusteltavissa olevia rasitusmittareita voitu kokeilla, vaan niistä valittiin yksi, jota pyrittiin käyttämään hyväksi mahdollisimman tehokkaasti ja järkevästi. Järjestelmää ajavalle palvelimelle asetettiin suorituskyvyn tarkkailija, joka tutki aikaa, jonka jokainen yksittäinen http-pyyntö viettää palvelimen ylläpitämässä pyyntöjen jonossa ennen kuin se on toteutettu loppuun asti. Jos oletetaan verkkoviiveet ja käyttäjän työasemasta aiheutuvat viiveet mitättömiksi, saadaan tästä hyvä approksimaatio ajalle, joka kuluu käyttäjän lähettämästä pyynnöstä (esimerkiksi napin painamisesta) siihen, että uusi sivu on latautunut käyttäjälle. Juuri tämä aika on erittäin tärkeä käyttömukavuuden mittari. Testauksen periaate on samanlainen kuin edellisessäkin kohdassa. Yhtäaikaisten keinokäyttäjien määrää muutetaan, ja joka kerralla otetaan tilastollista dataa talteen Puutteita CenterTest tarjoaa mahdollisuuden testata sivustoja kuormituksen lisäksi toimivuuden suhteen. Tällainen testaus edellyttää kuitenkin testitapausten laadintaa Visual Basic.NET skriptikielellä. Arvioitu työmäärä on yli tunti testitapausta kohden, ja tulosten luotettavuuden varmistamiseksi vaaditaan lisäksi manuaalista testausta. Näistä syistä ja resurssien vähyyden vuoksi testausta CenterTestillä toiminnallisuuksien suhteen ei toteutettu ohjelmatyöprojektissa. CenterTest laskee testiaineistoista testiajokohtaisesti tilastollisia tunnuslukuja, kuten diskreetin aikakeskiarvon pyyntöjen määrästä aikayksikköä kohden. Saatavien erilaisten tunnuslukujen määrä on kuitenkin varsin rajoitettu. Esimerkiksi testiajokohtaista tai edes kaikkien testiajojen yli laskettua keskihajontaa diskreetin ajan suhteen CenterTest ei laske. Tämä asettaa rajoituksia virheanalyysille, jolla ainoa mahdollinen toteutusmenetelmä on toistokoe. Toistokokeiden toteutusmahdollisuudet ohjelmatyöprojektissa ovat kuitenkin varsin mitättömät, joten tästä syystä virheanalyysi jouduttiin jättämään varsin huonoon asemaan. Tätä on analysoitu lisää luvussa 4.

6 3. Toteutuksen kulku Rasitustestaus toteutettiin lauantaina aamupäivällä. Testaajina toimivat Mikko Lampi ja Matti Peltomäki. Lauantaiaamun valinnalla pyrittiin löytämään ajankohta, jolloin liikenne Innofactorin verkossa olisi tarpeeksi pieni. Kesken testauksen havaittiin, että valinta epäonnistui. Kun testausta oli suoritettu muutama tunti, huomattiin, että toiseen projektiin liittyviä C#-käännöksiä ajettiin fyysisesti samalla palvelimella, jota rasitustestauksessa rasitettiin. Tästä johtuen testauksen loppuosan tulokset eivät ole luotettavia ja niissä esiintyy anomalioita, joille ainoa löydetty järkevä selitys on edellä kuvattu. Testauksessa tutkittiin ensin tiedonsiirtoaikaa yhteyksien lukumäärän funktiona noin kaksi tuntia, sitten pyyntöjen jonotusaikaa hieman yli kaksi tuntia. Testaus aloitettiin 9:50 ja se oli ohi noin 14: Tulosten analysointia 4.1. Tiedonsiirtoaika yhteyksien funktiona Ensimmäiseksi tutkittiin tiedonsiirtoaikaa yhteyksien funktiona. Seuraavassa kuvassa on esitetty sekä TTLB että TTFB. Kuvaajasta huomataan selkeä epälineaarinen muoto. Pystyakselin yksikkönä on millisekunti, vaaka-akselin yksikkönä yhtäaikaisten yhteyksien määrä Pyyntöjen jonostusaika yhteyksien funktiona Vastaavalla tavalla piirrettiin graafi pyyntöjen jonostusajasta yhteyksien funktiona. Tällä kertaa CenterTest ei tarjonnut mahdollisuutta piirtää dataa, mutta Microsoft Excelin toimintojen avulla tuloksista saatiin havainnollinen esitys. Kuvaaja on esitetty alla.

7 Request Wait Time versus Connections Maximum Average 25 percent ile 50 percent ile 75 percent ile Simultaneous Browser Connections Kuvaajaan on piirretty keskiarvojen lisäksi maksimiarvo ja neljännespersentiilit. Hyödyksi on käytetty kaikki CenterTestin tarjoama numeerinen data. Puutteena tässä kohtaa voidaan pitää sitä, että persentiileistä saadaan irti vain neljännespersentiilit mielivaltaisten persentiilien asemesta. Pystyakselin yksikkönä on millisekunti, vaaka-akselin yksikkönä yhtäaikaisten yhteyksien määrä. Tässä kohdassa käytetiin huomattavasti suurempaa suurinta yhtäaikaisten yhteyksien määrää kuin edellisessä kohdassa, millä pyrittiin havaitsemaan mahdollinen epälineaarinen käytös suurilla yhteyksien lukumäärän arvoilla Havaintoja Luvussa 4.1. esitetyssä graafissa on selkeästi epälineaarinen muoto, mutta katsomalla tulosten skaalaa huomataan, että tiedonsiirtoajat pysyvät varsin pieninä pienillä (<100) yhtäaikaisten käyttäjien määrällä. Koska ohjelmiston suunniteltu käyttäjäkunta on PK-yritysten työntekijät, on varsin oletettavaa, että yhdellä resurssienhallintajärjestelmällä ei ole yli sataa yhtäaikaista käyttäjää. Edellinen tulos on luonnollisesti pätevä silloin, kun yhdellä fyysisellä palvelinkoneella ajetaan tasan yhtä resurssienhallintajärjestelmää. Mikäli tulee tapauksia, joissa sama palvelinkone jaetaan useamman järjestelmän kesken, tulee miettiä tulosten pätevyyttä edes lineaarisesti skaalattuna uudelleen. Lisäksi tulos on funktio palvelimen laitteistokonfiguraatiosta. Vastaavasti tilanne, jossa yhden resurssienhallintajärjestelmän kuorma on hajautettu usealle palvelimelle on mahdollinen. Tässä saadut tulokset kertovat lähinnä, että alle sadan yhtäaikaisen käyttäjän järjestelmässä tämä ei ole tarpeellista. Luvussa 4.2. esitettyjen tulosten tulkinta on kumuloituneiden häiriötekijöiden vuoksi huomattavasti hankalampaa. Saatua raakaa numeerista dataa ja sen visualisointia lukuunottamatta, mitään johtopäätöksiä ei liene mahdollista esittää.

8 4.4. Häiriötekijöistä Luvuissa 2 ja 3 todettiin, että projektin rasistustestausajot kärsivät häiriötekijöistä niiden ennaltaehkäisy-yrityksestä huolimatta. Tässä luvussa kyseiset häiriötekijät on kuvattu yksityiskohtaisesti. Testauksen aika pyrittiin valitsemaan siten, että liikenne verkossa ja palvelimen muu käyttö olisi mahdollisimman vähäistä. Tässä epäonnistuttiin. Testauksen aikana Innofactorissa oli fyysisesti töissä kolme ohjelmoijaa, joista kaikki käyttivät kohteena ollutta palvelinta jollain tavoin ja ainakin yksi ajoi raskaita käännösprosesseja. Häiriötekijöiden varma poistaminen olisi vaatinut tietoa siitä, milloin palvelimella on työkäyttöä ja milloin ei. Tällaista tietoa ei ollut saatavilla.