OpenTele Server Performance Test Rapport

Transkript

1 OpenTele Server Performance Test Rapport 17. marts 2015 Side 1 af 22

2 1Indholdsfortegnelse Indholdsfortegnelse Indledning Test forudsætning Beskrivelse af testscenarier Test af OpenTele kliniker web interface Gennemgang af test skridt Login Patient overblik Patient målinger Patient måling Beskeder Grafer Anvendt software og hardware til test Testværktøj Anvendt database Webcontainer Hardware Performance test gennemførsel Test af OpenTele klient API Gennemgang af test skridt Anvendt software til test Testværktøj Anvendt database Webcontainer Hardware Performance test gennemførsel Præsentation af testresultater Resultat for OpenTele kliniker web interface Akkumuleret svartid som funktion af antal samtidige brugere Patientoverblik svartid som funktion af antal samtidige brugere Vælg patient svartid som funktion af antal samtidige brugere Patient grafer svartid som funktion af antal samtidige brugere Opsummering Resultat for OpenTele klient API Side 2 af 22

3 Akkumuleret svartid som funktion af samtidige brugere Patient login svartid som funktion af samtidige brugere Send besked svartid som funktion af samtidige brugere Vis spørgeskemaer svartid som funktion af samtidige brugere Opsummering Roadmap for forbedring af performance Opsummering Dokumenthistorik Side 3 af 22

4 2Indledning Indeværende dokument er den foreløbige rapport over performance testen af OpenTele server softwaren. Testen er foretaget på version af OpenTele, i forbindelse med Sprint 47. Dokumentet beskriver følgende: Test forudsætninger Beskrivelse af testscenarier Præsentation af testresultater Forslag til aktiviteter i fremadrettede testscenarier Opsummering. 3Test forudsætning Performance test af OpenTele server er udført under følgende forudsætninger: Forudsætning Begrundelse Konsekvens Performance test foretaget mod MySQL database. Performance test foretaget på en laptop, som både anvendes som server, database og til at køre performance tests. Performance test består primært af læsninger. MySQL databasen giver et testmiljø der minder mere om et produktionsmiljø, da vi har en rigtig SQL database til at opbevare vores data i, fremfor en flad fil. Anvendelse af enkelt miljø mindsker opsætningsomkostning og muliggør hurtigt opbygning test scenarier. Simpel test logik, og nemt at skalere op. I tilfælde af f.eks. patientoprettelse skal performance test være mere intelligent og kompleks f.eks. pga. krav om unikke CPR numre. MySQL giver en bedre performance og mere retvisende testresultater ift. at afspejle et rigtigt produktionsmiljø. En performance forringelse, da samme maskine både skal generere load samt agere web-, applikations- og database server. I produktionsopsætning vil appserver og database oftest være delt ud på flere maskiner. Testmetoden kan også forbedre performance, idet problemer med overdrevent mange roundtrips mellem app-server og database ikke ses så tydeligt, når database og app-server afvikles på samme maskine. Det er primært læsning og søgning, som testes igennem nuværende performance test, samt enkelte oprettelser. Side 4 af 22

5 4Beskrivelse af testscenarier Der er anvendt 2 primære testscenarier: 1. Test af OpenTele kliniker web interface 2. Test af OpenTele patient API. Disse vil blive gennemgået i efterfølgende afsnit. 4.1 Test af OpenTele kliniker web interface Serveren bliver instantieret med 61 klinikere og 514 patienter Gennemgang af test skridt Følgende test skridt er anvendt som skabelon for selve performance testen. Den røde ellipse indikerer, hvor der er trykket næste for at komme videre i testscenariet. Side 5 af 22

6 Login Side 6 af 22

7 Patient overblik Patient målinger Side 7 af 22

8 Patient måling Side 8 af 22

9 Beskeder Grafer Log ud som sidste skridt i testen. Side 9 af 22

10 4.1.2 Anvendt software og hardware til test Testværktøj Gatling v Anvendt database MySQL v Webcontainer Apache Tomcat instantieret via Grails Hardware Macbook Pro (Retina, 15-inch, Mid 2014) Processor: 2,5 GHz Intel Core i7 Memory: 16 GB 1600 MHz DDR3 Graphics: Intel Iris Pro 1536 MB Performance test gennemførsel De ovenstående beskrevne test skridt (se afsnit 4.1.1) er anvendt som brugsmønster. Testen er afviklet således: 1 samtidig bruger 5 samtidige brugere 10 samtidige brugere 20 samtidige brugere 40 samtidige brugere 60 samtidige brugere 80 samtidige brugere 100 samtidige brugere Ved flere samtidige brugere tilføjes en bruger i sekundet, indtil det maksimale antal brugere er nået. Der er mellem 5 og 10 sekunders pause mellem hvert request for at efterligne virkelige brugere. 4.2 Test af OpenTele klient API Interfacet mellem klient og server testes ved at lave en række forespørgsler som: henter og sender beskeder henter en liste over spørgeskemaer henter specifikke spørgeskemaer Gennemgang af test skridt Følgende test skridt er anvendt som skabelon for selve performancetesten: 1. Patienten logger ind. 2. Patienten klikker på beskeder og venter 10 til 30 sekunder. Side 10 af 22

11 3. Patienten sender en besked og venter 5 sekunder. 4. Patienten klikker på spørgeskemaer og venter 5 sekunder. 5. Patienten vælger et spørgeskema Anvendt software til test Testværktøj Gatling v Anvendt database MySQL v Webcontainer Apache Tomcat instantieret via Grails Hardware Macbook Pro (Retina, 15-inch, Mid 2014) Processor: 2,5 GHz Intel Core i7 Memory: 16 GB 1600 MHz DDR3 Graphics: Intel Iris Pro 1536 MB Performance test gennemførsel De ovenstående beskrevne test skridt (se afsnit 4.2.1) er anvendt som brugsmønster. Da testen er kortere for klient API et foretages testen ved at tilføje flere brugere i sekundet: 1 bruger i sekundet 2 brugere i sekundet 3 brugere i sekundet 4 brugere i sekundet 5 brugere i sekundet over 100 sekunder. 5Præsentation af testresultater I dette afsnit præsenterer vi resultaterne af ovenstående performance tests. Først gennemgås resultaterne for performance test mod OpenTele kliniker web interfacet og derefter performance test for OpenTele klient API et. Det er kun de væsentligste resultater som er vist. En mere detaljeret rapport kan findes i zip arkivet: opentele-performance-tests zip 5.1 Resultat for OpenTele kliniker web interface I dette afsnit præsenterer vi resultaterne for test af OpenTele kliniker web interfacet. Side 11 af 22

12 Når vi i nedenstående grafer anvender begrebet x samtidige brugere, menes der at vi opretter x antal brugere over x sekunder som løbende udfører testscenariet for OpenTele kliniker web interfacet. Dette betyder at der i starten og slutningen af testscenariet er færre end x samtidige brugere Akkumuleret svartid som funktion af antal samtidige brugere I ovenstående graf vises akkumulerede værdier for maksimum, 99-percentil, 95-percentil og gennemsnit for alle typer requests foretaget i løbet af testscenariet, hvor svartiden er funktion af antallet af samtidige brugere. Side 12 af 22

13 5.1.2 Patientoverblik svartid som funktion af antal samtidige brugere I ovenstående graf vises svartider for patientoverblikket som funktion af antallet af samtidige brugere. Her ligger svartiden stabilt indtil 40 samtidige brugere, hvorefter svartiden begynder at stige eksponentielt. Side 13 af 22

14 5.1.3 Vælg patient svartid som funktion af antal samtidige brugere Svartiderne for valg af patient viser samme tendens som svartiderne for patientoverblikket: en eksponentiel stigning når antallet af samtidige brugere overstiger 40. Ligeledes ses denne tendens også for svartider for målinger som dog ikke er afbildet i denne rapport. Side 14 af 22

15 5.1.4 Patient grafer svartid som funktion af antal samtidige brugere Ud over requests relateret til patientoverblikket og målinger, så ses der også store spikes for requests lavet til patient grafer Opsummering - Som det især ses i så begynder der at ske en klar eksponentiel stigning når antallet af samtidige brugere overstiger Ud over ovenstående resultater, så vil requests til find patient uden parametre være potentielt særdeles langsom, da søgningen henter alle patienter ud af databasen og for hver af dem laver en række beregninger. Dette er den forventede opførsel, men brugeren bør evt. advares mod at søgningen tager lang tid. Alternativt bør søgningen kun vise de X første resultater. - Med hundrede samtidige brugere begynder 'Patient Overview', 'Choose Patient' og 'Measurements' at tage 5-10 sek i gennemsnit og op til sek for max tid. Side 15 af 22

16 - Lazy evaluering af indhold kan også have en påvirkning på testresultaterne og især maksimum værdierne. 5.2 Resultat for OpenTele klient API I dette afsnit præsenterer vi resultaterne for test af OpenTele klient API et. I modsætning til det tidligere afsnit betyder x samtidige brugere i dette afsnit at vi opretter x antal brugere over 100 sekunder fremfor x sekunder. Dette betyder stadig at der i starten og slutningen af testscenariet vil være færre end x samtidige brugere Akkumuleret svartid som funktion af samtidige brugere I ovenstående graf vises akkumulerede værdier for maksimum, 99-percentil, 95-percentil og gennemsnit for alle typer requests foretaget i løbet af testscenariet, hvor svartiden er funktion af antallet af samtidige brugere. Side 16 af 22

17 5.2.2 Patient login svartid som funktion af samtidige brugere I ovenstående graf vises svartider for patient login som funktion af antallet af samtidige brugere. Her ligger svartiden stabilt indtil 300 samtidige brugere, hvorefter svartiderne tager et voldsomt hop og de første kald begynder at fejle pga. loadet. Side 17 af 22

18 5.2.3 Send besked svartid som funktion af samtidige brugere Tendensen er den samme for grafen over svartiden for indsendelse af beskeder hvor hoppet fra 300 til 400 brugere påvirker performance dramatisk. Side 18 af 22

19 5.2.4 Vis spørgeskemaer svartid som funktion af samtidige brugere Ligeledes gælder dette også for visning af listen af spørgeskemaer samt enkelte spørgeskemaer at hoppet sker ved 300 samtidige brugere Opsummering - Ifølge testen udviser serveren lineær skalerbarhed indtil 300 samtidige brugere, hvorefter responstiden begynder at stige voldsomt (dog ikke nødvendigvis eksponentielt). - Yderligere så begynder 1% af requests at fejle når der er 400 samtidige brugere, hvilket stiger til 5% når antallet af samtidige brugere stiger til 500. Side 19 af 22

20 6Roadmap for forbedring af performance I forbindelse med performancetesten blev tidligt identificeret et problem i forbindelse med overdreven hentning af brugeroplysninger. Problemet blev rettet, da performancetesten ellers ikke på retvisende vis kunne gennemføres. I performancetesten er en række problemstillinger identificeret. Følgende yderligere tiltag bør gennemføres for at få bedre målingsresultater, samt mere konkret viden om hvorvidt de identificerede problemer skyldes test-opstillingen, eller konkrete problemer i systemet som f.eks. kan rettes ved optimering af kildekoden eller af systemets underliggende database: Test bør udføres på hardware opsætning, som minder om egentlige produktionsmiljøer. Dvs. optimalt set på den virtuelle driftsplatform hos Region Nordjylland. Test bør udføres mod en (produktions-)database, som er tunet og optimeret. Test bør udføres mod en webcontainer, som er optimeret og tunet til produktionsbrug. Test bør udføres mod en server, som logger mindre end serveren anvendt i test. Test bør udføres således at test driver (klientmaskine) er på en anden maskine end selve serveren. Optimalt skal test driveren distribueres på flere maskiner. Test bør udføres på forskellige opsætninger for at afgøre om det er den givne maskine, Gatling eller selve systemet der er skyld i de klare hop ved hhv. 40 og 300 samtidige brugere i resultaterne. Årsagen til ovennævnte hop skal identificeres, og en plan for rettelse udarbejdes. Test mod kliniker web interfacet bør omfatte opdateringer frem for primært læsninger. Test mod klient API bør omfatte indsendelse af spørgeskemabesvarelser. Test bør også afbilde transaktioner i sekundet, som funktion af samtidige brugere, ud over svartider. 7Opsummering For OpenTele kliniker web interfacet har performance testen påvist (med de beskrevne forudsætninger), at systemet kan fungere effektivt indtil 40 samtidige brugere hvorefter svartiderne begynder at stige eksponentielt. Dog forbliver den gennemsnitlige svartid under 5 sekunder med 100 samtidige brugere. Ligeledes viste performance testen at OpenTele klient API en kan håndtere 300 samtidige brugere (med meget lav svartid) før svartiderne begynder at stige voldsomt og requests begynder at fejle. Side 20 af 22

21 Yderligere tests bør foretages på andre testopsætninger for at undersøge hvad den klare eksponentielle stigning skyldes. Hvis denne stigning skyldes selve systemet, så bør de requests som er afbildet i sektion 5 undersøges yderligere for at identificere potentielle flaskehalse. De rå gatling test resultater samt csv-filer og gnuplot kode kan findes i zip arkivet: openteleperformance-tests zip, Side 21 af 22

22 8Dokumenthistorik Version Dato Initialer Ændring PU Dokument oprettet Side 22 af 22