Uppnå och upprätthålla prestanda
 Skydda mot prestandaförsämring medan systemet används och allt eftersom det utvecklas. |
|---|
Utveckling är inte en engångsinsats. Det är en pågående process. Förvänta dig ändringar i prestanda när funktionerna ändras. Det finns varians i användarmönster och profiler, även ändringar från optimeringar i andra Azure Well-Architected-pelare. Alla ändringar kan belasta arbetsbelastningsresurser.
Valv skydda systemet från ändringar så att det inte skjuts tillbaka på prestandamål. Integrera testning och övervakning i utvecklingsprocessen. Testa systemets prestanda i produktion med verklig belastning och simulera den belastningen med automatiserad testning före produktion. I båda fallen bör du ha övervakningsmetoder på plats i verifieringssyfte.
Under hela utvecklingslivscykeln utför du olika typer av tester i olika skeden. I de inledande stegen testar du konceptbeviset för att se till att prestandaresultaten inte är helt oväntade. Under utvecklingens gång utför du manuella tester med låg ansträngning för att fastställa riktmärken. I byggfasen börjar du utveckla automatiserade rutinprestandatester som utvärderar svarstid, stressnivåer, belastningskapacitet och andra egenskaper som definierats i testplanerna.
Övervakningen måste vara en integrerad del av denna insats i stället för att vara en isolerad övning. Du kan se hur systemet och dess resurser presterar över tid. Du kan sedan finjustera dem för att maximera deras värde och se till att de fortsätter att uppfylla prestandastandarder.
Tänk på att prestandamålen varierar över tid, som svar på ändringar. Uppdatera prestandamodellen baserat på testade och övervakade mått. Ange tydligt ökad, minskad eller ingen effekt på flödenas prestanda.
Var alltid redo att omförhandla och återställa förväntningarna med affärsintressenter.
Exempelscenario
Contoso Event Solutions erbjuder en produkt som evenemangspersonal kan använda för att skanna biljetter på en mobil enhet och snabbt tillåta inträde till en biljettplats för de auktoriserade. Systemet är tillgängligt med både ett helt offlineläge och även som en molnansluten version för platser som är oroliga för biljettduplicering. Offlineläget är mycket högpresterande, men onlineläget saknade sina prestandamål. Utvecklingsteamet investerade nyligen ett par utvecklingscykler för att arbeta med det, och nu förbättras prestandan mycket och uppfyller målen. Affärsintressenter vill utöka sin kundbas för att stödja större lokaler snart.
Testa prestanda under utveckling
Formalisera prestandatester som kvalitetsgrindar som kan godkänna eller neka lanseringshöjning och den slutliga distributionen till produktion.
Dessa kontrollpunkter ser till att varje steg i distributionen uppfyller de prestandastandarder som krävs innan du fortsätter till nästa. Kontrollpunkterna hjälper till att förhindra oavsiktlig prestandaregression. Om prestandan till exempel är betydligt lägre än förväntningarna kan du blockera en version tills förbättringar har gjorts.
Contosos utmaning
- Teamet har investerat mycket tid och arbete för att uppnå acceptabel prestanda för onlineversionen av programmet, men de har för närvarande inget system på plats för att förhindra en regression.
- Nästa funktion som de planerar att lägga till är möjligheten för en plats att välja att visa en bild av deltagaren tillsammans med genomsökningen för ytterligare verifiering. Det finns en risk att den extra fotosökningen och nedladdningen saktar ner processen.
- Utan en formell process på plats finns det en risk att prestandan för både online- och offlineversionerna kan påverkas negativt av de ytterligare funktionerna och att de kan hamna under sina mål.
Tillämpa metoden och resultaten
- Teamet integrerar automatiserade prestandatester i bygg-pipelinen. Genom att implementera strikta prestandabaserade "go/no-go"-kriterier i bygg-pipelinen är teamet mer säkra på att den nya funktionen inte kommer att släppas med en prestandaregression.
- Teamet var klokt att implementera den här testningen eftersom den upptäckte en bugg i den senaste versionen av bygget. Buggen tvingade appen att försöka ansluta till Internet för att ladda ned en bild medan skannern var inställd på offlineläge, vilket gjorde att en timeout uppnåddes vid varje biljettsökning. Genom att fånga den här buggen med den automatiserade testningen kunde teamet åtgärda felet innan den nya versionen släpptes.
Optimera genom observerbarhet
Konfigurera en upprepningsbar process för övervakning av verkliga transaktioner i produktion och avvikelser mot dina prestandamål. Dessutom kan du använda syntetiska transaktioner i produktion och konfigurera övervakningsaviseringar för prestandaregressioner.
Du vill ha insikt i systemets faktiska prestanda under verklig belastning som inte kunde simuleras genom tester. Sedan kan du proaktivt identifiera problem och förbättringsområden, till exempel potentiella flaskhalsar, underutnyttjda resurser och andra problem.
Contosos utmaning
- Under en händelse där de använder validering av onlinebiljett används serverdelssystemet i hög grad.
- Det finns ett system för övervakning av programprestanda (APM), men det har inte använts för att övervaka hälsotillståndet för produktionstransaktioner.
Tillämpa metoden och resultaten
- Teamet har beslutat att anta uppdaterade processer för att bättre samla in hälsomått:
- De konfigurerar aviseringar baserat på prestandaprocentiler och prestandaavvikelser. Inga aviseringar indikerar att systemet presterar i acceptabla intervall för de flesta biljettgenomsökningar.
- När en offlinehändelse har slutförts laddas telemetrin för biljettgenomsökningar upp i batch och dessa mått går också igenom en process för att söka efter avvikelser från acceptabel prestanda.
- Teamet implementerar även syntetisk transaktionstestning för att utöka prestandaövervakningen. Eftersom nästan alla händelser äger rum på helger och på kvällen använder teamet syntetiska transaktionstester under hela veckan för att generera en mer konsekvent prestandabaslinje.
Hantera arbetsbelastningsändringar intelligent
Åtgärda prestandaerosion när användningen ökar, funktionerna ändras och data ackumuleras över tid för att upprätthålla prestanda. Återställ förväntningarna och etablera nya mål, om finjustering endast ger kortsiktiga fördelar.
Genom att använda den här metoden kan du bevara prestandatillståndet innan försämringen utvecklas till problem som påverkar användarupplevelsen negativt utöver det acceptabla intervallet.
Om du ändrar mål återställs prestandamodellen och du slösar inte tid på att optimera systemet som redan har nått sin kapacitet.
Contosos utmaning
- Säljteamet har aggressivt registrerat nya evenemangsplatser i systemet. Affärer är bra.
- Arbetsbelastningsövervakningssystemet har börjat märka att prestandabudgeten blir uppäten till mer och mer över tid, även utan att nya funktioner introduceras.
- Utan en ändring kan den här banan leda till en oacceptabel regression i prestanda, vilket gör att arbetsbelastningen riskerar att drabbas av ett avbrott om en incident inträffar.
Tillämpa metoden och resultaten
- Teamet inser att när fler kunder registrerar sig gör datasökningsmekanismen för onlinehändelser en mycket stor genomsökning av data för många frågor.
- En del frågeoptimering har hjälpt till att förhindra att den ökade användningen orsakar ytterligare skada. Under de kommande månaderna planerar teamet att dela upp olika händelser i olika datapartitioner för att minska behovet av frågegenomsökning. Detta stöder fortsatt utskalning av arbetsbelastningen.
- De inser också att de kan optimera systemet ytterligare för att växa genom att ta bort biljettdata från gamla händelser. Att söka efter gamla händelser är inte något som biljettvalideringssystemet behöver göra, så att data kan flyttas till ett arkiv som är dedikerat för rapportering och historisk sökning.