Checklista – Testning för prestandaeffektivitet

Testas programmet för prestanda, skalbarhet och återhämtning?

Prestandatestning hjälper till att underhålla system korrekt och åtgärda fel innan problem når systemanvändare. Det är en del av grundpelaren för prestandaeffektivitet i Microsoft Azure Well-Architected Framework.

Prestandatestning är supermängden för både belastnings- och stresstestning. Det primära målet med prestandatestning är att verifiera prestandatestbeteendet för programmet.

Belastningstestning verifierar programmets skalbarhet genom att snabbt eller gradvis öka belastningen på programmet tills det når ett tröskelvärde.

Stresstestning är en typ av negativ testning som omfattar olika aktiviteter för att överbelasta befintliga resurser och ta bort komponenter. Med den här testningen kan du förstå den övergripande återhämtningsförmågan och hur programmet svarar på problem.

Använd följande checklista för att granska programarkitekturen ur prestandatestningssynpunkt.

Prestandatestning

• Se till att du får en stabil prestandatestning med delat teamansvar. Det krävs ett antal resurser för att kunna implementera meningsfulla prestandatester. Det är inte bara en enskild utvecklare eller QA-analytiker som kör några tester på den lokala datorn. I stället behöver prestandatester en testmiljö (även kallat testtest) som tester kan köras mot utan att störa produktionsmiljöer och data. Prestandatestning kräver indata och engagemang från utvecklare, arkitekter, databasadministratörer och nätverksadministratörer.

• Kapacitetsplanering. Vid prestandatestning måste företaget kommunicera eventuella variationer i förväntad belastning. Belastningen kan påverkas av världshändelser, till exempel politiska, ekonomiska eller väderförändringar; av marknadsföringsinitiativ, till exempel försäljning eller kampanjer, eller efter säsongshändelser, till exempel helgdagar. Testa belastningsvariationer före händelser, inklusive oväntade, för att säkerställa att programmet kan skalas. Dessutom bör du se till att alla regioner kan skalas korrekt för att stödja total belastning om en region skulle misslyckas.

• Identifiera en väg framåt för att utnyttja befintliga tester eller skapa nya tester. Det finns olika typer av prestandatestning: belastningstestning, stresstestning, API-testning, klientsidan/webbläsartestning och så vidare. Det är viktigt att du förstår och formulerar de olika typerna av tester, tillsammans med deras fördelar och nackdelar, för kunden.

• Utför testning i alla steg i utvecklings- och distributionslivscykeln. Programkod, infrastrukturautomatisering och feltolerans bör testas. Detta kan säkerställa att programmet fungerar som förväntat i alla situationer. Du bör testa tillräckligt tidigt i programmets livscykel för att fånga upp och åtgärda fel. Fel är billigare att reparera när de fångas tidigt och kan vara dyra eller omöjliga att åtgärda senare. Mer information finns i Testa ditt program och Azure-miljön.

• Undvik att uppleva dåliga prestanda med att testa. Två delmängder av prestandatestning, belastningstestning och stresstestning, kan fastställa den övre gränsen respektive den högsta felpunkten för programmets kapacitet. Genom att utföra dessa tester kan du fastställa vilken infrastruktur som krävs för att stödja de förväntade arbetsbelastningarna.

• Planera för en belastningsbuffert för att hantera slumpmässiga toppar utan att överbelasta infrastrukturen. Om en normal systembelastning till exempel är begäranden per sekund ska infrastrukturen stödja begäranden med total kapacitet (till exempel 100,000100,000 begäranden per 80%125,000 sekund). Om du förväntar dig att programmet fortsätter att upprätthålla begäranden per sekund och den aktuella SKU:n (lagerhållningsenheten) introducerar svarstider vid begäranden per sekund behöver du troligen uppgradera produkten till nästa högre 100,00065,000 SKU. Om det finns en sekundär region måste du se till att den också stöder den högre SKU:n.

• Testa redundans i flera regioner. Testa hur lång tid det skulle ta för användarna att omdirigeras till den parkopplade regionen så att regionen inte misslyckas. Normalt kan ett planerat redundanstest hjälpa dig att avgöra hur lång tid som krävs för att fullständigt skala för att stödja den omdirigerade belastningen.

• Konfigurera miljön baserat på testresultat för att upprätthålla prestandaeffektivitet. Skala ut eller skala in för att hantera ökningar och minskningar i belastningen. Du kanske till exempel vet att du kommer att stöta på hög trafik under dagen och på låg nivå under helger. Du kan konfigurera miljön så att den skalar ut för ökningar i belastning eller inskalning för minskningar innan belastningen faktiskt ändras.

Testverktyg

• Välj testverktyg baserat på vilken typ av prestandatestning du försöker köra. Det finns olika verktyg för prestandatestning som är tillgängliga för DevOps. Vissa verktyg som JMeter utför endast testning mot slutpunkter och testar HTTP-statusar. Andra verktyg som K6 och Selenium kan utföra tester som även kontrollerar datakvalitet och variationer. Med förhandsversionen av Azure Load Testing kan du skapa ett belastningstest med hjälp av ett befintligt JMeter-skript och övervaka mått på klientsidan och serversidan för att identifiera prestandaflaskhalsar. Program Insights, även om det inte nödvändigtvis är utformat för att testa serverbelastningen, kan testa prestanda för ett program i användarens webbläsare.

• Utför prestandaprofilering och belastningstestning under utvecklingen, som en del av testrutinerna och före den slutliga versionen för att säkerställa att programmet fungerar och skalas efter behov. Den här testningen bör ske på samma typ av maskinvara som produktionsplattformen, och med samma typer, och kvantiteter av data och användarbelastning som den kommer att stöta på i produktion.

• Ta reda på om det är bättre att använda automatiserad eller manuell testning. Testningen kan vara automatiserad eller manuell. Att automatisera tester är det bästa sättet att se till att de körs. Beroende på hur ofta tester utförs är de vanligtvis begränsade i varaktighet och omfattning. Manuell testning körs mycket mer sällan.

• Cachelagra data för att förbättra prestanda, skalbarhet och tillgänglighet. Ju mer data du har, desto större blir fördelarna med cachelagring. Cachelagring fungerar vanligtvis väl med data som inte kan ändras eller som ändras sällan.

• Bestäm hur du ska hantera lokal utveckling och testning när statiskt innehåll förväntas hanteras från ett nätverk för innehållsleverans (CDN). Du kan till exempel fördistribuera innehållet till CDN som en del av versionsskriptet. Använd i stället kompileringsdirektiv eller flaggor för att styra hur programmet läser in resurserna. I felsökningsläge kan programmet till exempel läsa in statiska resurser från en lokal mapp. I produktionsläge använder programmet CDN.

• Simulera olika arbetsbelastningar i ditt program och mät programprestanda för varje arbetsbelastning. Den här tekniken är det bästa sättet att ta reda på vilka resurser du behöver som värd för ditt program. Använd prestandaindikatorer för att utvärdera om ditt program fungerar som förväntat eller inte.

Rekommendation

Definiera en teststrategi. Mer information finns i Testa.

Nästa steg