Azure Load Testing

Vi er mange i cVation, som er nysgerrige på hvad featuren kan i dag, så vi har brugt et hackaton på at eksperimentere med servicen. Denne blog beskriver hvad vi lærte og hvad der er på vores ønskeliste til udvidelser i fremtiden.

Motivation - Løbende load test, som en del af DevOps

Den åbenlyse motivation for at performanceteste er selvfølgelig, at sikre at en løsning performer under et realistisk brugerload. De fleste har nok prøvet at performanceteste en løsning inden go live, for så at opleve at løbende udvidelser og ændringer efter go live forringer performance. Det kan Azure Load testing hjælpe med at undgå, da det er bygget med henblik på ikke kun at køre load test én gang, men som en naturlig og automatisk del af en pipeline i Azure DevOps og GitHub Actions. Dermed sikrer man, at man opdager når kode comittes som forringer performance, hvilket gør det meget nemmere at identificere og rette problemet.

I pipelinen kan man definere forskellige accept-kriterier, så en pipeline fejler og evt. bremser et release hvis kriterierne er overskredet. Herunder ses et eksempel på en pipeline der fejler, fordi svartiderne fra en function overstiger 5 sekunder.

Design af load test

Azure Load Testing er bygget på Apache JMeter, som er et eksisterende værktøj til load test. Det har den fordel, at det har en del eksisterende features og hvis man allerede har load test i JMeter, så kan man nemt køre dem i Azure Load Testing. Desværre er JMeters klient program lidt tungt at komme i gang med og man føler sig hensat til 90'erne, når man bruger det. Men man kan heldigvis bare skrive xml'en direkte, så man slipper for JMeter UI.

JMeters xml åbner også for muligheden for at autogenerer sin load test. Så man kan skrive tooling, der f.eks. analyserer endpoints og bygger en load test baseret på det.

Testresultater

Azure Load Testing inkluderer også rapportering og sammenligning af test runs. Man kan vælge hvilke Azure ressourcer, som man vil se metrics for og hvis man f.eks. vælger at se metrics for en cosmos ressourcer, så vises RU forbrug og lignende relevant data. Rapporteringen er altså kontekst-afhængig af hvilke Azure ressourcer, der er en del af løsningen. Vi oplever dog at rapportering, og særligt sammenligning af resultater, ikke altid er retvisende. Derfor kan der være lidt bugs i preview-versionen på det her område.

Konklusion

Efter at have arbejdet med Azure Load testing på vores hackaton, så kan vi konkludere at vi ser en service fra Microsoft med potentiale, men også en service, der heller ikke er helt færdig. Det er nemt at integrere Azure Load Testing i eksisterende pipelines både i Azure DevOps og GitHub og man får en fin rapportering i Azure. Men det lader også til, at der er lidt bugs i visningen af testresultater.

Hvad savner vi? Man kan fint definere en præcis grænse, der skal få en pipeline til at fejle, men vi savner features som automatisk sender alerts omkring dårlig performance over tid. Vi ved Microsoft allerede har AI indbygget i Alerts til at fortælle når noget sker der er ud over normalen, så vi håber det også bliver godt integreret i Azure Load Testing.

Vi glæder os til at se den endelige version og forhåbentlig en masse features og forbedringer over tid.