Prestandajustera ett distribuerat program
I den här serien går vi igenom flera scenarier för molnprogram och visar hur ett utvecklingsteam använde belastningstester och mått för att diagnostisera prestandaproblem. De här artiklarna baseras på faktiska belastningstester som vi utförde vid utveckling av exempelprogram. Koden för varje scenario är tillgänglig på GitHub.
Scenarier:
Vad är prestanda?
Prestanda mäts ofta i form av dataflöde, svarstid och tillgänglighet. Prestandamålen bör baseras på affärsåtgärder. Kundriktade uppgifter kan omfattas av strängare krav än driftsuppgifter såsom generering av rapporter.
Definiera ett servicenivåmål (SLO) som definierar prestandamål för varje arbetsbelastning. Du uppnår vanligtvis det här målet genom att dela upp ett prestandamål i en uppsättning KPI:er (Key Performance Indicators), till exempel:
- Latens eller svarstid för specifika begäranden
- Antalet utförda begäranden per sekund
- Den hastighet med vilken systemet genererar undantag.
Prestandamål bör uttryckligen inkludera en målbelastning. Dessutom får inte alla användare exakt samma prestandanivå, även när de kommer åt systemet samtidigt och utför samma arbete. Därför bör ett servicenivåmål uttryckas i percentiler.
Ett exempel på servicenivåmål för kan vara: "Klientbegäranden har ett svar inom 500 ms @ P90, vid upp till 25 K-begäranden/sekund."
Utmaningar vid prestandajustering av ett distribuerat system
Det kan vara särskilt svårt att diagnostisera prestandaproblem i ett distribuerat program. Följande är några av utmaningarna:
En enskild affärstransaktion eller åtgärd omfattar vanligtvis flera komponenter i systemet. Det kan vara svårt att få en helhetsbild av en enda åtgärd från slutpunkt till slutpunkt.
Resursförbrukning distribueras mellan flera noder. För att få en konsekvent vy måste du aggregera loggar och mått på ett och samma ställe.
Molnet erbjuder elastisk skala. Autoskalning är en viktig teknik för att hantera toppar i belastningen, men det kan även dölja underliggande problem. Det kan dessutom vara svårt att veta vilka komponenter som behöver skalas och när.
Arbetsbelastningar skalas ofta inte över kärnor eller trådar. Det är viktigt att förstå kraven för dina arbetsbelastningar och titta på bättre optimerade storlekar. Vissa storlekar erbjuder begränsade kärnor och inaktiverad hypertrådning för att förbättra arbetsbelastningar med en kärnor och licensierade arbetsbelastningar per kärna.
Kaskadfel kan orsaka fel som är avlägsna från själva kärnproblemet. Det kan leda till att det första tecknet på problemet uppstår i en annan komponent än rotorsaken.
Allmänna metodtips
Prestandajustering är både en konst och en vetenskap, men det kan föras närmare vetenskapen med hjälp av en systematisk metod. Här följer viss bästa praxis:
Aktivera telemetri för att samla in mått. Instrumentera koden. Följ bästa praxis om övervakning. Använd korrelerad spårning så att du kan visa alla steg i en transaktion.
Övervaka percentilerna 90/95/99, inte bara medelvärdet. Medelvärdet kan dölja extremvärden. Samplingsfrekvensen för mått är också viktig. Om samplingsfrekvensen är för låg kan den dölja toppar eller extremvärden som kan tyda på problem.
Åtgärda en flaskhals i taget. Bilda en hypotes och testa den genom att ändra en variabel i taget. När en flaskhals tas bort upptäcks ofta en till flaskhals uppströms eller nedströms.
Fel och upprepade försök kan ha stor inverkan på prestanda. Om du ser att serverdelstjänster begränsar systemet skalar du ut eller försöker optimera användningen (till exempel genom att justera databasfrågor).
Leta efter vanliga antimönster gällande prestanda.
Leta efter möjligheter att parallellisera. Två vanliga källor av flaskhalsar är meddelandeköer och databaser. I båda dessa fall kan horisontell partitionering vara användbart. Mer information finns i avsnittet om horisontell, vertikal och funktionell datapartitionering. Leta efter heta partitioner som kan tyda på överbalanserade läs- eller skrivbelastningar.
Nästa steg
Läsa scenarierna om prestandajustering