En sammanfattande bild av prestandatest

Performance testing explained in one image

Prestandatest kan vara det roligaste som finns inom hela IT-svängen. Det finns många sätt att beskriva prestandatest, men en bild som jag återkommer gång efter gång till är den nedan.

Performance testing might be the most exciting thing to do in the whole of the IT industry. There are so many ways to describe performance testing, but there is one image that I keep returning to. It's the one below-

För att förstå denna bild kan vi använda följande förklaringar, förklarat utifrån arbetsgången:

To understand the picture above, we could use the following explanations - based vaguely on the work process:

1. Prestandapåverkande faktorer

   Factors affecting performance

   Som ett fundament behöver man ha koll på eventuella prestandapåverkande faktorer. Man måste inte nödvändigtvis ha järnkoll på alla inför ett test, men om man stöter på prestandarelaterade problem kommer man att behöva borra i dessa ordentligt.

   The foundation of any performance test is grasping the factors potentially affecting performance. You don't have to know everything about all of these prior to a test but if performance related problems are encountered during the test execution you may need to be able to drill down with these thoroughly.

   Dessa prestandapåverkande faktorer inkluderar t.ex. bakgrundslast, datamängder, produktionsplanering, konfigurationshantering, parametrar/settings/inställningar, miljöutseende, nätverkskonfiguration, arkitektur, applikationsimplementation, prestandakrav, användningsfall, användarrättigheter o.s.v.

   These factors include e.g. background load on network and server, data volumes in the database, production planning, configuration, parameters/settings, environment setup, network layout, architecture, application implementation, performance requirements, user scenarios, load scenarios, user rights and much more.

2. Förutsättningar och omständigheter

   Conditions and circumstances

   Att utvärdera prestanda underlättas av att ha en tydlig målbild. Ibland uttrycks förväntningarna i prestanda i mer eller mindre luddiga icke-funktionella krav, men ofta får vi göra utforskande prestandatester, kommunicera resultaten och låta någon bestämma om det är resultat som kräver åtgärd. Tilliten till resultaten av utforskande prestandatester underlättas även de av kännedom om den förväntade lastfördelningen och idéer om förväntad lastvolym.

   Assessing performance is far easier if you have a clear evaluation goal. Sometimes performance requirements are expressed as non-functional requirements and are rarely detailed enough to be used for testing directly but have to be interpreted. Another approach is using exploratory performance tests where you measure the system behaviour under load then informs about the findings for someone who can take decisions if further attention or actions are needed. The trust in the validity of the test results of explanations testing is increased the more you know of the expectations of the system load.

   En annan del av förutsättningarna är att förstå hur lasttestmiljön skiljer sig från tänkt produktionsläge för att underlätta analys av lastgenereringen och förståelsen för testresultaten.

   Knowing what differs between the test environment and the intended production environment is also crucial for creating a representative load on the system - and for the analysis of the data from the test.

   Syftet med prestandatestet är en annan viktig förutsättning. Vill man testa överlast/stresstest, är det ett funktionellt volymtest, vill man mäta upp systemet eller är det ett långtidstest för att identifiera resursläckage?

   The reason for the performance test is another important circumstance. Is the goal to assess the behaviour of a stressed system, a functional volume test, measuring performance behaviour, or long-term test to identify resource consumption over time?

   Även specifika omständigheter som t.ex. kampanjer, växande datamängder och sådana faktorer är värt att beakta inför prestandatester.

   Specific circumstances like planned marketing campaigns, growing data volumes over time and similar factors are also worth noting before any performance test.

3. Lastgenerering

   Load generation

   Utifrån förutsättningarna utvecklas ett lastscenario och något sätt att generera tänkt last tas fram. Att skapa pålitliga genererade laster är en specifik skillset. Detta skillset inbegriper ofta även att se till lämpligt testdata, användarkonton, behörigheter och liknande finns tillgängligt vid körtillfället.

   Det kan också vara värt att notera att vissa lastscenarion kräver last från flera olika maskiner, kanske fysiskt placerade på olika platser eller med olika IP-adresser för att hantera säkerhetsfunktioner eller lastbalansering - eller för att utvärdera hur svarstiderna är från olika världsdelar.

   It could be worth noting that certain types of load scenarios require load generated from several different machines. They could be physically located at different sites, or with different IP addresses to cope with security limitations, or load balancing - or to assess response times from different continents.

   Based on the conditions and circumstances a load scenario to generate expected load is developed. Creating reliable mechanisms to generate known load upon a system is a specific skillset. Often this skillset includes identifying usable test data, user accounts, user rights and more assets needed for load test execution.

   Det finns mängder av sätt att skapa last. Man kan köra script, köa upp meddelanden, spela in och spela upp transaktioner från produktionsmiljön, koordinera manuella användare och massor av andra kreativa sätt. Oftast begränsas dock detta av status på data i systemens databaser.

   There are numerous different methods of creating a load upon a system. For example, you could use a performance testing tool to create and run scripts, you could temporarily shut down a MQ broker to queue up messages and then start the broker up again, you could coordinate human testers for load generation, record and playback transactions against the system, and loads of other creative ways. The number one factor determining method to use is the state data in the affected databases since load testing generally consumes huge volumes of test data that need to be in the right state for the test scenario.

   Glöm inte att lägga till verifieringspunkter i att det är korrekt data som man får från servern.

   Never forget to include server response data verifications in your load generation.

4. Mätetal och monitorering

   Metrics and monitoring

   Det går att lägga på en last på ett system utan att mäta något och bara hoppas på att märka om något går dåligt. Man får dock mycket bättre utkomst av ett prestandatest om man har koll på resursanvändningen av servrar och nätverkskomponenter och mäter svarstider på klient och server.

   You could apply a load to a system without measuring anything, hoping to notice if anything out of the ordinary happens. But you'll get far more information if you setup to monitor resource utilization of servers, application, and network components - while also measuring response times on both client and server sides.

   Som absolut allra minst bör man monitorera sin lastgenerator så att det inte är den som bottnar.

   To the very least your load generator should be monitored to make sure the load generator is not the bottleneck.

5. Testkörning

   Test execution

   När lastgenereringsmöjligheterna är på plats och miljön är förberedd för monitorering sker själva testkörningen. Inför testkörningen bör man ha varskott berörda om att det kommer att ske prestandatester i miljön eftersom det kan uppstå knasigheter även i andra system om t.ex. nätverkskomponenter överlastas eller så. Vid testkörningen är det bra att samla en intressentgrupp av nätverkstekniker, applikationsexperter och prestandatestare för att underlätta analys och felsökning.

   When the load generation is ready, and monitoring is setup it's time for the load test execution. Before the load test you should make sure every stakeholder is aware of the load test since a load test execution might affect far more than the system under test if for example, some network components get saturated. During the test execution it's good practice to get a stakeholder group together consisting of network engineers, application experts, test manager, and performance testers. Having everyone in contact with each other makes analysis and debugging a lot easier.

   Det kan vara en god idé att under testkörningen även då och då gå in med en manuell klient vid sidan av scripten för att känna på, och kanske ta tid på, upplevelsen av systemets prestanda. Det händer att den skiljer sig väsentligt mot den uppmätta prestandan beroende på hur sidor laddas eller tjänster utförs.

   It's generally considered a good idea to use a manual probing client to evaluate the experience of the system under load. The perceived performance of system might differ significantly from the measured performance.

6. Analys

   Analysis

   Utifrån data och upplevelser från prestandatestkörningen kan man borra vidare och dra slutsatser. Eventuellt dokumenteras dessa och sparas undan till eventuella jämförande tester i framtiden.

   Based on drilling down in collected data from the test execution conclusions are drawn. Results are probably documented and stored for future comparative tests.