Prestandatest i CI/CD-flödet: Shifting left inom prestandatestning

I varje DevOps-ambition blir det snabbt tydligt att man måste tänka helt nytt kring prestandatester - speciellt när man lägger ut systemen i molnet där dålig prestanda snabbt blir väldigt dyrbart. Denna artikel föreslår ett sätt att få in prestandatester i sin befintliga CI/CD-pipeline.

En utmaning som många har när CI/CD introducerats är hur prestandatester förflyttas in i det kontinuerliga flödet. Det blir snabbt tydligt varför storskaliga prestandatester är ett skillset som tar många år att bli bra på. Ett sätt (att komma runt detta?) är att komplettera med APM-verktyg*, men de är reaktiva och fungerar dessutom bäst i infrastrukturer som stöder A/B-testning och liknande - vilket ganska få systemarkitekturer idag stöder.

Vad kan då testas smidigt redan i utvecklingsflödet? Testmiljöer kopplade till CI-servrar är oftast inte ens nära att vara bestyckade och konfigurerade som i produktion (även för många som gått all-in på IaC, Infrastruktur som kod), så ibland hör jag argument för att det är omöjligt att göra prestandatester i CI/CD-flödet. Det är visserligen ofta omöjligt att i dessa fullödigt testa för infrastrukturella kapacitetsbegränsningar eftersom CI/CD-miljöerna innehåller minimala datavolymer osv. CI-testerna förväntas även gå fort, så det är inte någon idé att försöka utföra klassiska prestandatester, som test av produktionsplaneringsaktiviteter**, stresstester och långtidstester, för att finna resursläckage och liknande.

En prestandasäkringsåtgärd som ändå är möjligt att göra i CI/CD-flödet är att försöka säkra att koden kan prestera som tänkt. Då är i alla fall en prestandarisk borta.

Utvecklarna kan använda analysverktyg i sin IDE (Integrated Development Environment, deras personliga utvecklingsverktyg) för att identifiera flaskhalsar och prestandaproblem. Men ofta slarvas det med detta och det skapas sällan några regressionstester. Dessutom sker det bara i samband med själva utvecklingsprocessen. Att i prestandatester på CI/CD-servrar mäta resursnyttjandet på serversidan ger ganska lite information. Men det går att utföra vissa typer av tester, t.ex.:

• Samtidighetstester
• Svarstider på systemets endpoints (under låg last) för att säkra parallellitet.

Denna typ av tester kräver tyvärr en del kodande för att få till eftersom de kräver trådhantering och ihopsamling av testresultat. Många system är tröga vid allra första exekveringen (färdigkompilering av kod, populering av cachar, upprättande av interna trådpools-sessioner och liknande), vilket påverkar svarstider. Det gör att skapandet av denna typ av tester ofta blir bortprioriterade.

Ibland behövs bara en liten knuff över en låg tröskel.

För att underlätta för utvecklare att ta med enklare prestandatester i sina enhetstester har vi därför tagit fram dessa två små enkla bibliotek:

• JUnit-extension för Java: https://github.com/Zington/ParallelJUnit
• MsTest-extension för C#/.NET: https://dev.azure.com/zington/ParallelMsTest

Dessa hjälpmedel avser göra det enkelt att exekvera ett vanligt enhetstest i parallella trådar, och över tid, samtidigt som exekveringstiden verifieras. De samlar dessutom ihop resultatet från alla exekveringstrådar och rapporterar till ett aggregerat testresultat. Det ÄR inte fullskaliga prestandatester, men det är en hjälp på traven för att få in enkla prestandatester i ett CI/CD-flöde - utan att behöva lära sig nya verktyg.

Om du skulle vara intresserad av större prestandatester, eller hjälp att optimera in rätt tester vid rätt tillfälle i din utvecklingskedja, hör gärna av dig till Anders Eng (anders.eng@zingtongroup.com).

Happy testing.

* Application Performance Monitoring)
** Att hinna alla batch-körningar på en natt, under pågående last och backuptagning