Arkitekturstrategier för prestandatestning

Gäller denna Azure Well-Architected Framework-checklista för prestandaeffektivitet:

Prestandatestning är en icke-funktionell testmetod som används för att utvärdera hur en arbetsbelastning fungerar under olika förhållanden. Det hjälper dig att identifiera prestandaförsämring tidigt, åtgärda problem proaktivt och säkerställa fortsatt anpassning till serviceavtal.

När du mäter svarstider, dataflöde, resursanvändning och stabilitet samlar du in bevis för att din arbetsbelastning konsekvent uppfyller definierade mål och ger den prestandanivå som företaget kräver.

De viktigaste strategierna i den här artikeln bygger på de grundläggande testmetoderna som beskrivs i OE:09-arkitekturstrategier för testning. Vi rekommenderar att du granskar den artikeln först. Rekommendationerna i den här guiden är begränsade till prestanda och fokuserar på att uppnå prestandamål så att dina arbetsbelastningar förblir i linje med de affärsmål som utvecklas.

I följande tabell definieras viktiga prestandavillkor som används i den här artikeln.

Ange mätbara mål för dina prestandatester

Mätbara prestandamål omvandlar subjektiva förväntningar till objektiva kriterier som du kan testa och validera.

Definiera dina prestandamål och tilldela budgetar. Definiera och dokumentera specifika prestandamål, till exempel hur många samtidiga användare du behöver stöd för. Se till att dessa mål överensstämmer med dina servicenivåmål och omvandla dem till mätbara testmål.

Tilldela prestanda- och felbudgetar för olika lager av din arbetsbelastning. När prestandatesterna misslyckas hjälper dina budgetar dig att identifiera vilket lager som är ansvarigt och var du ska fokusera optimeringsarbetet. Utan budgetar säger misslyckade tester bara att prestandamål inte uppfylls, inte var problemet ligger.

Du kan till exempel ange budgetar på 400 ms för API-svarstid, 150 ms för databasfrågor och ett tak på 1% för misslyckade begäranden. När ett test misslyckas kan du kontrollera varje lagers resultat mot dess budget för att avgöra om problemet är långsamma API-svar, långsamma databasfrågor eller en ökning av fel.

Definiera acceptanskriterier med tydliga tröskelvärden för passering och fel. Basera dina acceptanskriterier på prestandamått som svarstid, svarstider, dataflöde, resursanvändning, felfrekvenser och andra prestandaindikatorer som överensstämmer med dina prestandamål.

Definiera tröskelvärden för varje mått så att dina tester ger tydliga resultat för passering eller fel. Om din SLO kräver 95% begäranden för att slutföras inom 200 ms anger du tröskelvärdet för API-svarstid till 200 ms vid den 95:e percentilen. Alla testkörningar där den 95:e percentilen överskrider 200 ms är ett fel.

Starta tidigt och testa kontinuerligt

Tidig prestandaanalys fångar upp flaskhalsar i arkitekturen innan de blir kostsamma att åtgärda.

Starta prestandatestningen så tidigt som möjligt i arbetsbelastningens livscykel för programvaruutveckling. Du behöver inte en komplett applikation för att börja. Utvecklare kan profilera kod lokalt, mäta svarstider och identifiera resursintensiva åtgärder. Tidig testning informerar designbeslut, validerar arkitektoniska val mot prestandamål och identifierar optimeringsmöjligheter.

Testa din arbetsbelastning kontinuerligt allt eftersom den utvecklas för att uppfylla nya krav. Varje kodändring kan medföra prestandaregressioner. Kör tester regelbundet för att fånga dessa ändringar tidigt. Införliva prestandatester i distributionspipelines och kör periodiska automatiserade tester för att identifiera prestandaavvikelser innan den når produktion.

Avvägning. Tidig prestandatestning kräver dedikerad infrastruktur och specialiserad expertis, vilket ökar driftskostnaderna. Balansera den här investeringen mot kostnaden för prestandaproblem som upptäckts sent och produktionsincidenter.

Testa under verkliga förhållanden

Prestandatester bör matcha verkliga förhållanden så att dina resultat är meningsfulla.

Spegla produktionsmiljön

Testmiljön bör spegla produktionen så nära som praktiskt. Skräddarsy din metod för miljön baserat på din arbetsbelastnings riskprofil.

För verksamhetskritiska arbetsbelastningar matchar du produktionen exakt över:

• Beräknings-SKU:er och konfigurationer
• Inställningar för automatisk skalning
• Cachelagringskonfigurationer
• Nätverksförhållanden (svarstid, bandbredd)
• Externa beroenden

För icke-kritiska arbetsbelastningar kan testning i en nedskalad miljö som efterliknar produktion ge användbara insikter till lägre kostnad.

Förhindra konfigurationsavvikelse. Konfigurationsavvikelse kan leda till missvisande testresultat. Implementera automatiserade kontroller för att verifiera att testmiljön matchar produktionen. Se till att rätt versioner distribueras innan du kör tester.

Avvägning. Fullständig produktionsreplikering för prestandatestning ökar infrastrukturkostnaderna avsevärt. Utvärdera om risken för prestandaproblem i produktionen motiverar kostnaden för dedikerad infrastruktur för prestandatestning för din arbetsbelastning.

Verifiera prestanda i produktion

Testmiljöer kan inte helt replikera verkliga förhållanden som påverkar prestanda. Produktionstester exponerar problem som endast uppstår under faktisk användning och ger korrekta baslinjer för framtida optimering. Vissa prestandakrav kan bara verifieras där verkliga användare, data och infrastruktur korsar varandra.

Kör kontrollerad produktionstestning. Schemalägg tester under icke-punkttid för att förstå hur din arbetsbelastning beter sig vid resursuttömning och återhämtar sig från fel.

Produktionstestning visar prestandaegenskaper under faktiska förhållanden, inklusive:

• Realistiska användarbeteendemönster och datavolymer
• Sann nätverkssvarstid och bandbreddsvariationer
• Geografiska distributionseffekter
• Api-prestanda och beroenden från tredje part
• Verkligt cachelagringsbeteende och infrastrukturegenskaper

Använd progressiva testtekniker. Börja med små procentandelar av trafiken och öka gradvis. Övervaka svarstider, dataflöde, felfrekvenser och resursanvändning i varje steg. Den här gradvisa metoden begränsar risken samtidigt som man identifierar brytpunkten, avslöjar flaskhalsar och ger en korrekt bild av systemets beteende under ökande efterfrågan.

Övervaka produktionstester kontinuerligt för att hitta problem tidigt. Implementera automatiserade skyddsåtgärder som stoppar tester om de påverkar användarna negativt, till exempel automatiserade återställningsmekanismer och realtidsaviseringar. Dessa tekniker säkerställer snabba svar och minimerar störningar.

Risk: Produktionstestning påverkar verkliga kunder direkt eftersom det kan skapa extra belastning och störa trafiken. Implementera alltid skyddsåtgärder, begränsa exponeringen och ha återställningsplaner som är redo att minimera potentiella affärspåverkan. Balansera fördelarna med realistisk testning mot de potentiella affärseffekterna av att störa liveanvändare.

Verifiera ändringar med hypotesdrivna experiment

Använd hypotesdrivna experiment för att vägleda prestandatestningen. Utforma enskilda prestandaexperiment så att de ger meningsfulla resultat.

Börja med en fokuserad hypotes om arbetsbelastningens prestanda och definiera mätbara framgångskriterier som leder till åtgärdsbara beslut. Din hypotes kan till exempel vara: "Om du lägger till ett index i ordertabellen minskar frågetiden med 70% under hög belastning." Baslinjen är det aktuella schemat och varianten är schemat med det nya indexet. Kör samma belastningstest mot båda versionerna. Samla in frågesvarstid, användning av databas-CPU och dataflöde och jämför sedan resultat för att avgöra om hypotesen är sann.

Avvägning. Hypotesdrivna experiment kräver att samma tester körs mot både baslinje- och variantkonfigurationer, vilket ökar infrastrukturkostnaderna och testkörningstiden. Fokusera experiment på ändringar med hög effekt där den potentiella prestandavinsten motiverar den ytterligare testningen.

Använda flera typer av prestandatest

Prestandatestning omfattar en rad tester som utvärderar hastighet, stabilitet och skalbarhet under olika förhållanden. Varje testtyp riktar sig till olika prestandaaspekter för din arbetsbelastning. Den avslöjar unika insikter och möjliggör en fullständig utvärdering som går utöver funktionell testning.

Använd flera testtyper för att verifiera din arbetsbelastning från olika vinklar. Stresstestning hittar till exempel brytpunkten under hög belastning, men endast uthållighetstester avslöjar minnesläckor som dyker upp över timmar eller dagar.

Välj testtyper baserat på vad du behöver verifiera.

I följande tabell visas när du ska använda varje testtyp och vad den visar om din arbetsbelastning. Även om den här tabellen inte är en fullständig lista fungerar den som ett belysande exempel.

Försök inte implementera alla testtyper omedelbart. Börja med grundläggande belastningstestning för att förstå baslinjeprestanda. När du identifierar risker och får erfarenhet kan du utöka till stresstestning, topptestning och slutligen uthållighetstestning.

Avvägning. Prestandatestning för alla testtyper kräver betydande tids- och infrastrukturinvesteringar. Matcha din testinvestering med din affärsrisk.

Använda verkliga användningsmönster och dataegenskaper

Testning med realistiska data ger korrekta insikter om resursförbrukning, systembeteende och dolda prestandaproblem.

Skapa olika testdatauppsättningar som representerar olika scenarier, användarprofiler och datavolymer. Använd indatavariationer och randomisering för att efterlikna verklig användarmångfald. Inkludera gränsfall som kan orsaka prestandaproblem, till exempel stora nyttolaster, komplexa frågor eller hög samtidighet.

Dina testdata bör se ut som verkliga produktionsdata. Använd syntetiska data som har egenskaper för produktionsdata. Reservera produktionsdatauppsättningar (korrekt anonymiserade) för vissa scenarier, till exempel för att markera datahanteringsbeteenden som transaktionskonsekvens, svarstid och volymhantering.

Simulera syntetiska transaktioner som efterliknar verkliga användararbetsflöden. Skripta dessa transaktioner och kör dem upprepade gånger för att generera belastning som återspeglar hur din arbetsbelastning faktiskt används.

Dina testscenarier bör återspegla faktiska användningsmönster, till exempel samtidig användaråtkomst, perioder med hög belastning och specifika transaktionssekvenser. Se till att scenarierna överensstämmer med affärsmålen så att prestandaresultaten återspeglar det sanna användarvärdet.

När du testar under belastning ska du inkludera faktiska API-anrop från tredje part. Att håna externa beroenden gör att tester körs snabbare och mer förutsägbart, men det döljer verkliga prestandaproblem. Om din app är beroende av ett API för betalningsprocessor testar du med verkliga anrop för att förstå svarstiden från slutpunkt till slutpunkt.

Använda testresultat för att vägleda designbeslut

Dina testresultat styr designbesluten genom att fastställa tillförlitliga baslinjer och vägleda optimeringsarbetet.

Upprätta dina baslinjemätningar. Baslinjer hjälper dig att identifiera trender och avvikelser och om optimeringsändringar ger förbättringar. Du behöver tillförlitliga baslinjer för att spåra prestandatrender över tid.

Registrera prestandamått under de första testerna. Den här inspelningen är din baslinje, en ögonblicksbild av "normal" prestanda. I efterföljande körningar jämför du nya resultat med den här baslinjen för att identifiera prestandaändringar. Överväg användarpåverkan, frekvens, kostnader för korrigering och risk för ändringskriterier när du undersöker data för att förstå systemets beteende under olika förhållanden. Leta efter mönster som visar var prestanda försämras. Använd den här insikten för att prioritera optimeringsarbetet.

Optimering är en iterativ process och bör styras av data. Reservera dedikerad tid i utvecklingscykeln för prestandaoptimering. Använd dina baslinjer för att mäta effekten av ändringar och se till att de ger de förväntade förbättringarna utan att införa regressioner.

Korrelera prestanda med affärsmått. Ansluta prestandaförbättringar till affärsresultat som intäkter, användarengagemang, kundnöjdhet och konverteringsfrekvens för att motivera fortsatta investeringar i prestandaoptimering.

Håll testtillgångarna i linje med aktuella användningsmönster

Dina prestandatesttillgångar innehåller viktig kunskap om arbetsbelastningens förväntade beteende, godtagbara prestandatrösklar och realistiska trafikmönster.

Ordna testsviter efter typ. Håll belastningstester, stresstester och uthållighetstester i separata sviter. Blanda dem inte. Varje typ har olika konfigurationskrav, körningsvaraktighet och framgångsvillkor. Organiserade sviter gör det enklare att köra riktade tester, jämföra resultat mellan körningar och underhålla varje svit separat.

Uppdatera testdata regelbundet. Föråldrad testdata leder till orealistiska resultat. Återskapa testdata så att de återspeglar aktuella egenskaper för produktionsdata när datamodellen ändras, datavolymerna växer eller användardemografin ändras.

Granska testscenarier när din arbetsbelastning utvecklas. Schemalägg regelbundna granskningar för att säkerställa att dina scenarier fortfarande återspeglar den faktiska användningen. Scenarier blir inaktuella som:

• Användarbeteendet skiftar över tid
• Trafikmönstren ändras när användarbasen växer
• Nya funktioner introducerar olika användningsmönster
• Infrastrukturen kan skala för att möta nya kapacitetskrav

Azure-stöd

Azure-pipelines kan du integrera prestandatestning i CI/CD-pipelinen. Du kan lägga till belastningstestning som ett steg i pipelinen för att verifiera prestanda och skalbarhet för dina program.

Azure Chaos Studio hjälper dig att mata in verkliga fel i ditt program så att du kan köra kontrollerade felinmatningsexperiment. Experimenten hjälper dig att mäta, förstå och förbättra din molnprogram- och tjänstresiliens.

Azure Load Testing är en belastningstestningstjänst som genererar hög skalbar belastning för alla program. Belastningstestning ger funktioner för att automatisera belastningstester och integrera dem i ditt CI/CD-arbetsflöde (kontinuerlig integrering och kontinuerlig leverans). Du kan definiera testvillkor, till exempel genomsnittlig svarstid eller tröskelvärden för fel, och automatiskt stoppa belastningstester baserat på specifika felvillkor. Belastningstestning erbjuder en instrumentpanel som tillhandahåller liveuppdateringar och detaljerade resursmått för Azure-programkomponenter under ett belastningstest. Du kan analysera testresultaten, identifiera flaskhalsar i prestanda och jämföra flera testkörningar för att förstå prestandaregressioner över tid.

Azure Monitor är en omfattande övervakningslösning för att samla in, analysera och svara på telemetri från dina molnmiljöer och lokala miljöer. Application Insights är ett tillägg av Monitor som tillhandahåller APM-funktioner. Du kan använda Application Insights för att övervaka program under utveckling och testning och även i produktion.

Relaterade länkar

• Rekommendationer för säkerhetstestning
• Rekommendationer för att utforma en strategi för tillförlitlighetstestning

Checklista för prestandaeffektivitet

Se den fullständiga uppsättningen rekommendationer.