Utforma för att uppfylla kapacitetskrav
 Tillhandahålla tillräckligt med tillgång för att hantera förväntad efterfrågan. |
|---|
Det är viktigt att proaktivt mäta prestanda. Mätning av prestanda innebär att mäta baslinjer och att ha en preliminär förståelse för vilka komponenter i systemet som sannolikt kommer att utgöra utmaningar. Du kan uppnå det utan att utföra ett fullständigt prestandatest eller genom detaljerad optimering. Genom att vidta de här inledande stegen skapar du en grund för effektiv prestandahantering tidigt i utvecklingslivscykeln.
Granska systemet som helhet i stället för att fokusera på enskilda komponenter. Undvik finjustering i det här skedet. Att göra detaljerade prestandaförbättringar resulterar i kompromisser inom andra områden. När du går igenom livscykeln och påbörjar testning av användargodkännande eller går mot produktion kan du snabbt identifiera vilka områden som kräver ytterligare optimering.
Exempelscenario
Contoso Manufacturing har utvecklat en internt använd Java Spring-baserad mikrotjänstapp som används för att övervaka och optimera deras tillverkningsprocesser. Arbetsbelastningsteamet håller på att migrera appen, som för närvarande finns lokalt, till Azure.
Den Azure-värdbaserade appen kommer att byggas på Azure Spring Apps, Azure Database for MySQL och Azure IoT Hub. Contoso har en ExpressRoute-anslutning till Azure.
Utforma arbetsbelastningen effektivt
Välj rätt resurser i teknikstacken, vilket gör att du kan uppfylla prestandamålen och integrera med systemet. Överväg funktioner som kan uppfylla skalbarhetskraven och hitta rätt balans mellan resursallokering och systemkrav för att hantera oväntade ökningar effektivt.
Genom att analysera resursernas olika funktioner ser du till att varje komponent bidrar till systemets övergripande funktioner och prestanda, och du kan identifiera skalningsfunktioner som du kan dra nytta av.
Högerstorleksresurser kan uppfylla ändringar i efterfrågan utan överetablering, vilket leder till kostnadsbesparingar.
Contosos utmaning
- Den befintliga lokala appmiljöinfrastrukturen hanteras helt av Contoso, vilket innebär en betydande börda för teamet. De etablerar och underhåller för närvarande servrar, nätverk och lagring samt konfigurerar och uppdaterar Java Spring-tjänstens körning och alla beroenden.
- Teamet ser fram emot att migrera till en PaaS-modell med Azure Spring Apps, vilket gör att teamet kan fokusera mer av sin energi på att se till att deras program levererar det avsedda affärsvärdet och ägna mindre tid åt att hantera infrastrukturen.
- Det här programmet är viktigt för Contosos verksamhet och har strikta prestandakrav, så de måste se till att de teknikval de gör som en del av migreringen gör att de kan uppfylla dessa krav.
Tillämpa metoden och resultaten
- När de olika planerna har jämförts väljer teamet Azure Spring Apps Standard-planen, som tillhandahåller en fullständigt hanterad tjänst för Spring Boot-appar som är optimerad för produktionstrafik. Med högst 500 instanser per app kan Standard-planen tillhandahålla tillräckligt med beräkningskapacitet för maximal förväntad användning.
- Dessutom kan tjänsten konfigureras för att skala ut efter behov och skala in beräkningsresurser när den extra kapaciteten inte behövs.
- Teamet tittade på Enterprise-planen, som kan skala upp till 1 000 instanser per app, men bestämde sig för att de inte behöver den kapaciteten just nu. De är också övertygade om att de inte behöver den supportnivå som Enterprise-planen erbjuder, eller resten av dess exklusiva funktioner.
Prognostisera kapacitetsbehov korrekt
Gör kapacitetsplanering baserat på efterfrågan och kapaciteten hos valda resurser för att utöka din prestandamodell. Använd förutsägelsemodelleringstekniker för att förutse förväntade kapacitetsändringar som kan inträffa med förutsägbara och oväntade ändringar. Definiera prestandamål som kan översättas till tekniska krav.
Genom att använda den här metoden kan du effektivt använda resurser och möta efterfrågan utan överetablering, vilket undviker onödiga kostnader. Dessutom hjälper det dig att förstå hur designvalen påverkar prestanda.
Contosos utmaning
- För att maximera den effektiva användningen av produktionsmaskiner fungerar Contosos produktionslinje enligt ett cykliskt schema och producerar olika produkter vid olika tidpunkter på dagen.
- Varje produkt kräver olika åtgärder och därmed olika beräkningsbehov från kontrollprogrammet. Under övergången mellan produkter måste kontrollprogrammet utföra en mängd olika uppgifter som kräver ökad beräkningskapacitet, som att analysera data från den tidigare produktionskörningen och uppdatera kontrollalgoritmerna för datorerna.
Tillämpa metoden och resultaten
- För att möta den högre efterfrågan under övergångsperioderna identifierar teamet först de flöden som hanterar ändringsfunktionerna, dokumenterar deras prestandakrav och beräknar sina transaktionsvolymer baserat på den lokala versionen av programmet. Beväpnad med dessa data fortsätter teamet att uppskatta den beräkningskapacitet som krävs av de mikrotjänster som ingår i målflödena.
- Autoskalning konfigureras för dessa komponenter, vilket säkerställer att ytterligare resurser etableras före växelperioden och släpps efter att aktiviteterna har slutförts.
- Inställningarna för automatisk skalning justeras innan appen distribueras till produktion, baserat på den faktiska prestandan i den nya miljön.
Distribution av konceptbevis
Implementera ett konceptbevis (POC) som validerar de tekniska kraven och designvalen.
Ett konceptbevis är avgörande för att validera designen för att avgöra om systemet kan uppfylla prestandamålen och om dessa mål är realistiska. Baserat på den förväntade belastningen kan du kontrollera om förväntad kapacitet kan uppfylla prestandamålen.
Kontrollera även kostnadskonsekvenserna av designvalen.
Contosos utmaning
- Under utvecklingen utför teamet omfattande belastnings- och prestandatestning av programfunktionerna med hjälp av enhetssimulatorer och använder den här informationen för att optimera konfigurationen för automatisk skalning.
- En aspekt som kan påverka effektiviteten i konfigurationen av automatisk skalning är den potentiella nätverksfördröjningen som kommunicerar från Azure Spring Apps-miljön till IoT-enheterna på tillverkningsgolvet, som är anslutna till Azure via ExpressRoute. Teamet spekulerar i att svarstiden kommer att vara högre i Azure än för den lokala versionen om appen, och att svarstiden också kan påverkas av andra faktorer, till exempel tid på dagen eller enhetens plats.
- En ökning av svarstiden skulle sannolikt påverka transaktionsvolymen som varje mikrotjänstinstans skulle kunna bearbeta.
Tillämpa metoden och resultaten
- Teamet bestämmer sig för att distribuera en POC till Azure för att verifiera sina hypoteser och samla in mått som kan användas för att optimera konfigurationen. De skapar ett test av Azure Spring App för att kommunicera med IoT-enheter spridda över tillverkningsgolvet. IoT-enheterna är anslutna till det lokala nätverket och registreras med Azure IoT Hub. Testprogrammet ansluter slumpmässigt till enheterna hela dagen genom att skicka en enkel ping och registrerar den tid det tar att ta emot ett svar.
- De data som samlas in under denna POC, i kombination med resultatet av belastningstestningen, gör det möjligt för teamet att mer exakt uppskatta den beräkningskapacitet som behövs när de förbereder sig för den första produktionsstarten.
- Teamet tittar också på sätt att ytterligare förbättra testfallen som används för belastningstestning för att simulera mer realistiska svarstider baserat på lärdomarna från POC.