Performance Testing av IT løsninger. En liten hva og hvorfor på performance testing - Thor Olav Sørnmo, Teleplan Consulting

Transkript

1 Performance Testing av IT løsninger En liten hva og hvorfor på performance testing - Thor Olav Sørnmo, Teleplan Consulting

2 Om Teleplan Consulting Etablert i Langsiktig og solid privat eierskap Eget AS i Teleplan-gruppen, ca. 50 ansatte Leverer konsulenttjenester og rådgiving innen IKT-området Våre hovedkunder er større virksomheter med ansvar for samfunnskritiske oppgaver Jobber tett på kundene, ofte som en del av deres organisasjon eller i ledelsen av store prosjekter/programmer Omsetning Teleplan Consulting 2012: 105 MNOK QA sertifisert ISO 9001:2008 2

3 Om meg Seniorkonsulent Teleplan Consulting Jobbet med test i over 10 år Bakgrunn Test Engineer Unit 4 Agresso, Automatisering av funksjonell testing Testleder Det Norske Veritas Innføring av testrammeverk og test som tjeneste Testleder Forsvaret (Via TPC) Testrammeverk og operativ testleder for større infrastrukturløsning 3

4 Klient Server historikk I Utviklet av Xerox PARC på 70 tallet To roller i nettverket: Server og klient Server deler ressurser med distribuerte klienter 4

5 Klient Server historikk II Server har all logikk Klient består av «tynn» klient Lite prosessering på klient Server behandler data Stormaskinløsninger Terminalvindu Fordeler: Rask prosessering og sikre data Eks: Bank, forsikring, billettsystem 5

6 Klient Server evolusjon Paradigmeskifte Fra Stormaskin/terminal til Windowsbaserte løsninger Klientprosessering Data på server Raskere overføring av data Performance avhengig av klient «Tykk» klient Funksjonalitet på PC Ikke avhengig av konstant oppkobling mot server Fordel: Flere påloggede samtidige brukere 6

7 Klient Server evlusjon II Evolusjon: Performance krav øker Datamengder øker Ulempe med tykke klienter er låsing av data Løses ved å bruke webapplikasjoner Hybridløsninger med prosessering på klient og server God løsning så lenge utvikler er inneforstått med risikoen 7

8 Risikoen med klient server programmering Mange risiko med klient server programmering Performance på server i seg selv Avstand klient server Båndbredde Klientens evne til å prosessere data Mengde data som sendes mellom klient og server Valideringer og postback Etc... 8

9 Meldinger fra linjen «Vi har ikke performance problemer» «Vi har ingen utfordringer med pålogging» «Våre brukere er fornøyd de» 9

10 Meldinger fra IT og brukerne «Det er ingen som benytter denne løsningen!» «Ingen utenfor hovedkontoret benytter denne løsningen!» «Når vi kommer om morgenen tar vi en kaffe samtidig som vi logger på!» «Det er normalt å vente i 40 sekunder på innloggingen på løsningen» 10

11 There s no such thing as a free launch Den største trusselen mot et system er dens potensiale for å faktisk bli det man ønsker; en suksess: Netmagazine 2011 Top 5 failed web launches * #5 H&M Versace Collection launch #4 Harry Potter studio tour booking system #3 DirectGov e-valg #2 British National Lottery #1 Olympic Ticket Launch for London OL *) 11

12 Hva skjedde? Systemene knakk sammen på grunn av pågang De hadde ikke planlagt for trafikkøkning Testingen på det funksjonelle var god De glemte at de måtte skalere for sukssess Norsk eksempel på det samme: Altinn 2012 Billettservice ca Påmelding Birkebeinerrittet Det verste er: Alle skylder på en ting Brukerne - De hadde ikke forventet et så stort trykk 12

13 Risiko ved slike lanseringer Misfornøyde brukere er tapte brukere Suksess blir fort tap når løsningen feiler Potensialet er høyt Resultatet er i verste fall konkurs. Høyprofilerte prestisjeprosjekt blir mareritt for organisasjonen 13

14 Andre utfordringer: Chatty applications Hva er en chatty applikasjon? En ekstremt sosial applikasjon Liker mange spørsmål (request) Får mange svar (Response) Ikke så problematisk om man er lokalisert kort fra server Litt verre om man begynner å komme et stykke fra server 14

15 Hvordan avdekke slike utfordringer Lag en strategi for performancetest før utvikling starter Bruk solide verktøy for målinger og analyser Resultatene vil bli stilt spørsmål ved Benytt enkle målinger med tydelige start og slutt punkter F.eks: Login med brukernavn & passord Last ned x Mbyte data Lagre fil på server 15

16 Ulike scenarioer man bør teste Antall samtidige brukere på systemet Antall byte gjennom løsningen per sekund Gjentatt bruk over tid Performance degrade? 16

17 Scenario 1 Samtidige brukere Hvordan måle systemets kapasitet på samtidige brukere Hvor mange pålogginger per sekund før systemet går ned Hvor mye «browsing» kan man gjøre Hvilke parametere skal jeg sjekke Alle serverlogger CPU, Minne, nettverkstraffikk Klientoppførsel Hva skjer på klient nå server CPU går i 90%? 95%? 98%? Mål: Hvor mange brukere tåler 1 server uten at performance går ned? Sjekk så lastbalansering: Hva tåler 2 servere? Estimer så opp mot ønsket antall samtidige brukere 17

18 Resultater fra Scenario 1 Hva oppnår vi? En oversikt over potensialet til løsningen Skalerbarheten til løsningen Estimere behov for produksjonshardware Redesign av løsning om det er behov for det Balanse mellom kost-nytte effekt Hardware koster mye Lei jern i overgangsfase 18

19 Scenario 2 - Data I/O Mål på hva systemet kan håndtere av data Filserverhastighet Mål systemets kapasitet på data før nettverket er fullt Mål tid per fil opp og ned Databasehastigheter Oppdater felter Målepunkter Klient Server 1, Server 2, etc. CPU, nettverk, minne m.m. 19

20 Resultater fra Scenario 2 Her ser man om man har en løsning som tåler datamengder I tillegg kan man se om «lange» datastrømmer påvirker performance (Tar plass i oppkoblingsobjekter, se også Scenario 1) 20

21 Scenario 3 Performance over tid Løsninger er ofte ok i korte perioder Hva skjer i løpet av en time? En dag? En uke? Kan og bør testes Performance glitch skjer plutselig Må da analysere hva som skjer 21

22 Resultater fra scenario 3 Finner årsak til performance problemer som ikke skyldes hardware eller software Ofte logger som blir fulle Kjekt å avdekke før go-live Greit å monitorere over tid for å få følelse med hvor man skal tune en løsning på best mulig måte. 22

23 Baselining Hvordan kravstiller man performance? Mål mot dagens løsning i hvis dette er tilgjengelig Etabler en «common sense» forståelse Login: 3-5 sek maks Opplasting av dokument < 1 mb: 5-10 sek Samtidige brukere Dette danner basis for forståelse av performance 23

24 Weapon of choice HP LoadRunner Markedslederen innen performance testing Solid verktøy i fangst og analyse av resultater Avslører allerede i recordingfase om man kan ha utfordringer MS Visual Studio Test Suite Integrert performance test verktøy «Et tonn» med freeware 24

25 HP LoadRunner Recording av applikasjon ved «klikk og skript», VuGEN Lag transaksjoner man ønsker å måle på Etabler scenario i LoadRunner Legg inn logger fra ulike målinger man ønsker Kjør simulerte brukere Analyser resultat Veldig enkelt for basistester Kan øke kompleksitet med utviklingsteam 25

26 Return on Investment Du fanger opp utfordringer før og-live Du kan etablere og klargjøre for problemer som kan komme Sannsynligheten for å lykkes med lansering blir større. Sist men ikke minst 26

27 Fornøyde kunder og brukere 27