Prestandatestning och antimönster för molnprogram

Prestandaskydd, ungefär som designmönster, är vanliga defekta processer och implementeringar inom organisationer. Det här är vanliga metoder som kan orsaka skalbarhetsproblem när ett program är under press. Medvetenhet om dessa metoder kan bidra till att förenkla kommunikationen av övergripande begrepp mellan programvaruutövare, och kunskap om antimönster kan vara till hjälp när du granskar kod eller diagnostiserar prestandaproblem.

Här är ett vanligt scenario: Ett program fungerar bra under prestandatestning. Det släpps till produktion och börjar hantera verkliga arbetsbelastningar. Då börjar det fungera dåligt – avvisa användarbegäranden, stoppa eller utlösa undantag. Utvecklingsteamet står då inför två frågor:

• Varför dök inte det här beteendet upp under testning?
• Hur åtgärdar vi detta?

Svaret på den första frågan är enkelt. Det är svårt att simulera verkliga användare i en testmiljö, liksom deras beteendemönster och mängden arbete de kan utföra. Det enda helt säkra sättet att förstå hur ett system beter sig under belastning är att observera det i produktion. För att vara tydlig: vi föreslår inte att du borde hoppa över prestandatestningen. Prestandatestning är avgörande för att få baslinjeprestandamått. Men du måste vara beredd på att observera och korrigera prestandaproblem när de uppkommer i det aktiva systemet.

Svaret på den andra frågan, hur problemet ska åtgärdas, är inte lika enkelt. Flera olika faktorer kan vara bidragande och ibland visar sig problemet bara under vissa omständigheter. Instrumentering och loggning är nyckeln till att hitta rotorsaken men du måste även veta vad du letar efter.

Baserat på vårt arbete med Microsoft Azure-kunder har vi identifierat några av de vanligaste prestandaproblemen som kunderna ser i produktion. För varje antimönster beskriver vi varför det normalt inträffar, symtomen för antimönstret och metoderna för att lösa problemet. Vi tillhandahåller även exempelkod som illustrerar både antimönstret och en föreslagen skalbarhetslösning.

Vissa av dessa antimönster kan verka uppenbara när du läser beskrivningarna, men de förekommer oftare än du kanske tror. Ibland ärver ett program en design som fungerade lokalt men som inte kan skalanpassas i molnet. Eller så kan ett program börja med en mycket ren design men när nya funktioner läggs till kryper ett eller flera av de här antimönstren in. Oavsett vilket hjälper den här guiden dig att identifiera och åtgärda de här antimönstren.

Katalog med antimönster

Här är listan över de antimönster som vi har identifierat:

Antimönster	beskrivning
Upptagen databas	Avlastning av för mycket bearbetning till ett datalager.
Upptagen klientdel	Flytta resursintensiva uppgifter till bakgrundstrådar.
Trafikintensiva I/O	Många små nätverksbegäranden skickas kontinuerligt.
Överflödig hämtning	Hämtar mer data än vad som behövs, vilket resulterar i onödiga I/O.
Felaktig instansiering	Objekt som har designats för att delas och återanvändas skapas och raderas upprepade gånger.
Monolitisk beständighet	Samma datalagring används för data med mycket olika användningsmönster.
Ingen cachelagring	Data cachelagras inte.
Bullrig granne	En enskild klientorganisation använder en oproportionerlig mängd resurser.
Försök igen Storm	Försök igen misslyckade begäranden till en server för ofta.
Synkrona I/O	Blockering av anropstråden medan I/O slutförs.

Nästa steg

Mer information om prestandajustering finns i Prestandajustera ett distribuerat program