Prestandariskanalys

Version 1.5Version history:
Version 1.5 (2020-05-18) Separate print formatting added.
Version 1.4 (2020-05-17) Moved version history to tooltip. Improved introduction.
Version 1.3 (2020-05-16) Improved the note functionality
Version 1.2 (2020-05-16) Added more checklist items
Version 1.1 (2020-05-15) Added more introduction text
Version 1.0 (2020-05-14) Initial HTML version converted from Excel

Introduktion till domänområdet och till workshopen -

Kapacitet och prestanda är två viktiga kvalitetegenskaper. Det kan vara svårt att få kontroll så att man känner sig trygg med prestanda. Denna checklista är framtagen för att, i workshop-form ledd av en erfaren prestandaspecialist, identifiera hur man bäst ska förhålla sig till prestandarisker.

Upplägg för riskworkshop

Ett systems prestanda kan stjälpas av tusentals olika orsaker. Att få kontroll på alla dessa så att man känner sig trygg kan vara en utmaning. Denna utmaning blir ännu större när man går mot kontinuerliga produktionssättningar.

Som bäst brukar en sådan typ av workshop fungera om den leds av en erfaren prestandaspecialist och består av:

Systemägare eller någon som förstår hur systemanvändningsförändringar över tid sker.
Systemarkitekt eller senior utvecklare som förstår hur systemet fungerar tekniskt.
Eventuell testledare eller likande som förstår hur systemet egentligen fungerar utifrån sett och som vet vad som redan testats.
Eventuellt kan det vara bra med någon med budgetansvar (projektledare/systemansvarig) så att beslut kan fattas i slutet av mötet utan ytterligare förankring.

Effektiv prestandasäkring

Många gånger försöker man säkra prestandarisker så tidigt som det är lämpligt. Många typer av kodrelaterade problem går att lösa direkt i IDE:n, genom dess profilers.
Ytterligare andra, som samtidighetsbuggar, går att hitta i enhetstester som säkrar prestanda. Några kräver integrerade system med access till riktiga databaser snarare än de minnesdatabaser eller mockade databaser som är vanliga vid enhetstester.
Vissa typer av prestanaproblem, som onödiga full-table-scans i databaser, blir ett problem först vid produktionsvolymer av data - och ibland kanske först efter några års användning av systemet så att det har accumulerat tillräckligt mycket data för att det ska bli ett problem.

En del typer av prestandaproblem, som t.ex. suboptimalt konfigurerad middleware eller infrastruktur, eller dåligt indexerade databaser, eller IPS:er som är onödigt grundliga, kan behöva genomföra prestandatester på en högre nivå.
Vid denna typ av prestandatest skapar man skript som på protokollnivå simulerar en i väsentliga aspekter produktionslik last mot ett system. Under tiden lasten sakta ökas monitorerar man nyckelparametrar i resursanvändningen av systemet. Det kan röra sig om CPU, RAM, I/O, connection pool, kölängder, cache-nyttjande, svarstider, felfrekvens och mycket mer.

Risktyp	Åtgärd
Resurskrävande datatyper i kod	Profilers i IDE
Onödiga loopar i kod	Profilers i IDE, eller väldigt sent i APM-verktyg
Onödigt frekventa accesser till samma datapost (t.ex. metadata)	Mätning av läs- och skriv-lås under last
Svarstider för enskilda API endpoints	Automatiserade tester med rimliga testdatamängder i CI-pipeline
Icke-parallelliserade API:er	Enhetstester som testar parallellitet
Under- eller överdimensionerad connection pool	Nyttjandemätning under last
Felkonfigurerad cache	Verifierande tester
Resurskrävande SQL-anrop i kod (full table scan och liknande, eller felindexerat, eller tillkrånglat databasschema)	Profilers i DB Manager, eller genom ledtrådar från APM-verktyg
Felkonfigurerad middelware	Black-box prestandatester
Feluppskattad last (fler användare/transaktioner än trott)	APM-verktyg, aktiv övervakning i produktion
Felkonfigurerad infrastruktur (lastbalanserare o.dyl.)	Verifierande tester
Övernitiska IPS:er och andra säkerhetslösningar	Black-box prestandatester
Begränsad hårdvara eller otillräcklig resurstilldelning till virtualiserade serverkomponenter	Black-box-tester med monitorering av resurser
Missnöjda användare på grund av långa svarstider	Pålagd last på hela systemet kompletterat med probing client
Långsamt allt sämre prestanda över tid	Skapande av en massa poster i databaserna för att simulera framtida läge, därefter fullskaligt prestandatest
Incidenter på grund av fulla loggdiskar eller andra resurser som tar slut	Övervakning i produktion
Infrastruktursfunktioner som går fel (fail-over, spawnande av nya frontservrar o.s.v.)	Verifierande tester
Produktionsplanering som inte hinner med schemalagda jobb	Verifierande tester
Samtidighetsproblem (t.ex. deadlocks)	Verifierande integrationstester i CI-flödet

Denna lista kan göras hur lång som helst. Det viktiga att ta med sig är att säkra varje prestandarelaterad risk för sig.

Begrepp

Begrepp	Betydelse
Virtuell användare	En simulerad användare som använder systemet. Ibland är detta synonymt med antalet trådar mot systemet under test, men i t.ex. webbläsarbaserade system hämtas serverresurser med parallella trådar för varje användare.
Korrelering	I en kommunikation mellan en klient och en server fångas ett datafält ur ett svar från en server och återanvänds i senare request.
Parameterisering	Om man använder samma data i många parallella trådar testar man bara cache-funktioner. Man brukar därför parameterisera, byta ut, t.ex. användarkonto och liknande i en konversation mellan en klient och en server.
Monitorering	Kontinuerlig övervakning av relevanta mätpunkter på server, applikation, middleware och infrastruktur under last.
Användarscenario	De transaktioner som en simulerad (virtuell) användare av en viss kategori genomför i systemt.
Lastscenario	Viktad last över en testomgång. Hur skalas användarscenarion upp och ner.
Synkroniseringspunkt	Punkt i ett lastscenario där de virtuella (simulerade) användarna väntar in varandra. Används mest i samtidighetstester.
Probing client	En manuellt, eller automatiserad, hanterad applikationsklient som utför aktiviteter i den faktiska applikationsklienten undertiden en last ligger på systemet. Den används för att dels känna av upplevd svarstid och dels rimlighetsbedöma effekten av den pålagda lasten.

Olika övergripande strategier för att skapa last

Det finns flera olika sätt att se till att ett system nås av en last.

Kanalisera produktionslast

MQ-köer och liknande kan stoppas upp under några timmar (stänga ner broker-tjänsten). När den senare öppnas igen kan man mäta hur lång tid det tar för mottagande system att bearbeta de uppköade meddelandena och därigenom dra slutsatser över om kapaciteten är tillräcklig.

Verktyg som Oracles ORA genomför detta på transaktionsnivå i databaser. Man tar en snapshot av en databas och sparar sedan undan en logg med transaktioner som sker i produktion och läser sedan på dessa igen mot den undansparade snapshot av databasen för att mäta om kapaciteten är tillräcklig.

I event-store-arkitekturer är detta en väldigt tillgänglig metod att skapa verklighetstrogen last. En del använder detta för att dagligen kontrollera vad som hade hänt om man haft nattens applikationsbygge i produktion.

Skapa syntetisk last

Många prestandatestverktyg lägger på en syntetisk last mot systemet. Nästan alla dessa verktyg arbetar på transport-protokollnivå och skapar REST-anrop eller liknande mot ett system. Dessa paralleliseras sedan.

Några system använder handgrepp mer eller mindre fulla systemklienter för att skapa last (t.ex. MicroFocus TrueClient). Det ger ett ganska smidigt scriptskapande, men också stor footprint per virtuell användare.

Saker att tänka på

Prestandatester har en förmåga att konsumera enorma mängder testdata.
Det händer att man kör sönder systemen ordentligt i prestandatester - se till att backa upp miljön.
Tänk på att ett system ofta kan ge spill-laster till andra system under last. Förvarna dessa inför att man lägger på en last.
Validera mottaget data i kommunkationen. Det räcker inte att få svar. Svaret ska inte vara fel. Sessionsövertaganden och knasigheter är vanliga under last.
Var noga med vad du monitorerar under lastkörningen.
Det kan vara svårt att förstå vad som är rimlig och verklighetstypisk last att lägga på. Lägg möda på att analysera detta.

Testdatahantering vid storskaliga prestandatester

Det finns flera strategier för att hantera testdata i prestandatester. Vilken som är bäst beror på systemet och syftet med prestandatesten.

Använda produktionsdata

Ibland har man lyxen att kunna använda produktionsdata, antingen genom att datat i systemet har så tydlig och ensad struktur, eller att det bara är läsande tjänster och där data spelar mindre roll.

Skapa data inför testet

Ett prestandatestverktyg är utmärkt för att göra saker parallellt och repetitivt. Det kan användas genom att man skapar ett förberedelseskript som skapar upp en massa användbara ärenden i systemet inför ett test. Det kan vara bra att tänka på att man inte bör lägga på för tung last när dessa ärenden skapas upp eftersom det inte är ett lasttest.

Skapa data i testet

I de flesta IT-system har allt data ett livscykelflöde som beror på affärsflödena. Genom att göra script som följer affärsflödena hela vägen från att ett ärende (eller motsvarande) skapas till dess det avslutas så får man skript som är självförsörjande på sitt eget testdata.

Ta hjälp av de som förstår mer

Ofta går det att be en databasadministratör att ta fram en lista på användbara dataposter för ett test. Denna metod bygger också på att man betänker att det kan vara bra att ha återställningspunkter för miljön så att det går att göra omtester utan att man känner att man förbrukat data.

Vid denna metod blir det lite pyssligt att hålla på med indexuppräkning i data-listan vid varje provkörning av scripten vid scriptskapande.

Söka fram i realtid i skripten

Med denna metod får man även en kontroll på att man har förstått datastrukturen eftersom specialfall oundvikligen kommer upp. Det kan också bli väldigt mycket skriptande samt att utsökningen i sig riskerar att lägga på extra last som påverkar så att lastmönstret inte blir verklighetsaktigt.

Checklista

Syfte

•

Vilket syfte har testerna? Är det bara för att säkra prestanda eller är det någon som är oroligt för något särskilt?Ibland finns det bakomliggande kända risker eller farhågor. Dessa bör identifieras.

Ansvar

•

Vems ansvar är det att prestanda är säkrade?Belyser ansvarsfrågan och lyfter attention.

•

Vem ansvarar för att utföra eventuella prestandatester?Kod- och datastruktursrelaterade typer av prestandatester brukar hamna på teamen, men infrastruktur och SIT kan vara andras ansvar.

Projektet

•

Finns det några hålltider som är relevanta för säkringen av prestandan?Ibland är det hårt styrande deadlines som får sätta test-scopet, eller t.ex. frysperioder i testmiljöer.

•

Finns det planer på mjuk utrullning av releaser (A/B-tester, gruppvis utrullning, stegrande användning)?En mjuk utrullning av ett system ger en chans att identifiera applikationsmässiga begränsningar, om än inte infrastrukturella sådana.

•

Vilka kontaktpersoner är bra att ha?Ingen prestandaspecialist klarar sig helt på egen hand.

•

Hur får prestandaspecialisterna tillgång till relevant systemdokumentation (behörighet och länkar)?Ofta underlättar det att ha tillgång till testfall, systembeskrivningar och liknande.

•

Till vilka ska resultatet av prestandasäkrandet rapporteras?Främst funna problem och fel.

•

Hur ska rapporer och data från prestandasäkrandet förvaras i väntan på framtida prestandatester?Ofta kan det underlätta väsentligt att kunna jämföra utvärdera prestandadata mot tidigare genomförda körningar.

Systemet under test

•

Finns det med prestandatester i CI/CD-flödet? Finns det ett värde i att ha det?Om t.ex. endpoints parallellitet och svarstider är testat i CI/CD-flödet återstår det endast att säkra infrastrukturella risker samt datavolymsrisker.

•

Har man haft möjilghet att köra prestandarelaterade profilers i IDE? Har man gjort det?Om systemet är egenutvecklat kan man vinna mycket trygghet för kod- och datastrukturs-relaterade risker genom att köra prestandarelaterade hjälpmedel i IDE och DB-verktyg.

•

Finns det prestandarelaterade enhetstester? Vad borde dessa kompletteras med?Kontrollfråga för att undersöka utvecklarteamets förhållande till prestandasäkring - samt för att i inspirerande syfte väcka medvetenheten om att detta är görligt och bör finnas.

•

Vad är arkitekterna oroliga för?Ofta har ett systems lösningsarkitekter en förståelse för ett systems svaga delar och en direkt fråga till dessa är ofta bra för att få reda på dessa.

•

Vilken/vilka typ(er) av förändring har skett i användningsmönster, infrastruktur och system sedan senaste gången prestanda bevisligen fungerade väl?En förståelse både för förändringar i infrastruktur, lastmönster och systemet i sig är nödvändigt för en komplett bild.

•

Är testmiljöerna begränsade? Hur ska prestandatesterna förhålla sig till eventuell lastbalansering? Kan man simulera last mot en nod, eller måste man köra full last?Ibland är man hänvisad till att använda nerskalade miljöer för tester och det är väsentligt att veta i vilka aspekter dessa avspeglar verkligheten, och i vilka de inte gör det, för att veta vilka risker man kan bli trygg med i ett test - och vilka risker som kvarstår.

•

Finns det dokumenterade krav på prestanda/kapacitet?Ibland har man lyxen att ha definierade krav att arbeta mot. Annars kan det behövas utforskande prestandatester för att mäta upp prestanda så att det går att bedöma om den är tillräckligt bra.

•

Finns det en arkitekturbeskrivning att ta del av?Att ta del av någon form av SAD/arkitekturbeskrivning hjälper väsentligt för att förstå vilka risker som finns och vilka möjilgheter som finns för att interagera med systemet.

Historik

•

Har det genomförts prestandatester förr på detta testobjekt? När? Hur gick de?Detta kan ge ledtrådar till var risker finns idag, och vilka typer av risker som redan arbetats bort.

•

Finns det anledning att tro att lasten kommer att öka eller minska över tid?Ett system lever sällan ett statiskt liv. Det kan därför vara värt att fundera ett varv över framtida scenarion. Kommer data-mängden att öka? Kommer antalet användare att öka?

•

Har det tidigare funnits prestandarelaterade problem?Detta kan ge ledtrådar till var risker finns idag, och vilka typer av risker som redan arbetats bort.

Testtyp

•

Planeras robusthetstester under last? Fail-over, driftövervakning, larmsättning o.s.v.?Ibland kan det vara vettigt att passa på att testa fail-over, nodstarter, och liknande i samband med att ett system redan är under känd och konstant last.

•

Om stresstest är planerat; finns det tid för systemåterställning om det går ner?Det händer att system körs sönder under last. Om man befarar att det tar lång tid att återställa ett system efter krasch kan det vara värt att säkra backuper och planera för eventuell mjuk lastrampning.

•

Finns det tester för minnes- och andra resursläckage, eller ska man passa på att köra en långtidstest?En långtidstest får stå och gå med typiskt ca. halv nominell last under åtskiliga timmar, och så följer man kurvorna över minnesanvändning, disknyttjande och liknande för att se att inte dessa resurser kommer att ta slut vid drift.

•

Ska lasten läggas på samtidigt som tyngre schemalagda jobb körs?Att ha en last pålagd på ett system medan backupen tas, månadsomräkningar körs eller liknande kan identifiera specifika typer av samtidighetsfel.

Lastmönster

•

Finns det testfall färdiga för användning i prestandatest?Det kan finnas testfall som beskriver happyflow genom en applikation, och som går att skapa last utifrån. Det kan även röra sig om krav på genomströmning, antal samtidiga användare, förväntade svarstider, accepterad felfrekvens och liknande.

•

Vilken teknologi är inblandad i kommunikationen med systemet?Hjälper till att identifiera möjliga sätt att säkra prestanda.

•

Finns det anledning att routa lasten i ett lasttest på något särskilt sätt?Ibland står lastgeneratorer på "fel" nät jämfört med hur produktionslast - och stundom är det värt att routa om denna för att vara trygg med infrastrukturens leveransförmåga.

•

Finns det loggar från produktion eller annan data att använda för att prognostisera relevant last?Att veta vilken last som kan förväntas nå ett system kan vara en utmaning. Loggar, estimat, prognoser och liknande kan vara värdefull hjälp.

•

Vilka användargrupper är identifierade för att simulera last från? Hur är fördelningen dem emellan?Att känna förväntat lastmönster är en bra start för att säkra prestanda.

•

Finns det sätt att använda riktig produktionslast för att genomföra lasttester?Ibland kan man använda verklig last för att testa prestanda. Man kan stoppa MQ-köer en stund. Man kanske kan spara undan transaktioner från produktion. Man kanske kan registrera testsystemet som mottagare för produktionslast också?

•

Hur stor last ska vi planera för?För många lasttestverktyg styrs användningen av licenser, och större last tarvar då dyrare licenser. Ofta går det att hyra tillfälliga licenser om det behövs. Ibland sätter även lastgeneratorerna begränsningar i hur mycket last som går att generera.

•

Vad cachas i kommunikationen?Det finns cachar av olika slag, allt från nätverkskortets egna buffert, klient-cache, backend-cache i systemen, DB-cache i databasen o.s.v. Att förstå detta hjälper till att förstå hur en bra last är utformad för en viss test.

•

Finns det tidpunkter då lasten kan förväntas vara högre? Veckovis, månadsvis eller årsvis?De flesta system har vissa periodiska peakar. Dessa bör man ta höjd för i prestandasäkring. Glöm inte att även batch-jobb lägger last på systemet.

•

Finns det händelser som tillfälligt kan ge högre last? Nodbortfall? Kampanjer?En vanlig typ av allvarlig incident är när något fallerar och last spiller över på något annat istället. Därför är detta en viktig fråga att ställa.

•

Finns det anledning att, och förväntningar på, att testa med olika devices (telefoner, plattor)?Ibland skiljer sig backend-funktionaliteten väsentligt mellan olika devices, och då kan man behöva ta höjd för det i testerna.

Testmiljöer

•

Finns det en tänkt miljö för att köra testerna i?Tillförlitligheten för prestandatester beror mycket på begränsningar i de miljöer som finns. Hårdvarukapacitet, datamängder, integrationer, behörigheter o.s.v.

•

Behöver prestandaspecialisterna någon särskild access för att komma åt testmiljöerna?T.ex. behörigheter eller testkonton?

•

Finns det intressenter som bör notifieras innan prestandatest genomförs? Vilka?Det kan vara bra att informera berörda parter om att spillaster kan nå deras system inför ett testgenomförande.

•

Finns det begränsningar i testmiljön? Integrationer? Datamängder? Behörigheter? Nätverkskomponenter (IPS o.s.v.)?Tillförlitligheten för prestandatester beror mycket på begränsningar i de miljöer som finns. Hårdvarukapacitet, datamängder, integrationer, behörigheter o.s.v.

•

Är utökad loggning påslaget i testmiljön jämfört med i produktion?Loggning kan vara tungt för systemet att hantera, vilket påverkar prestanda. Det kan dock också göra det lättare att felsöka upptäckta problem.

•

Delar testmiljön hårdvara med andra applikationer som kan påverka prestanda?Det är vanligt att system genom virtualisering delar hårdvara med andra system. Det kan då vara värt att veta om det är något annat stort som händer i något annat system samtidigt.

•

Finns det möjlighet för återställning av systemet (främst dess data) om man vill upprepa en test?Prestandatester har en förmåga att konsumera testdata, och ett smidigt sätt att kunna köra om samma tester är att återställa data.

Mätetal

•

Vilka klientsides-mätetal kan vara relevanta? Svarstider? Felfrekvens? Mera?Mäter man för mycket är det svårt att identifiera flaskhalsar, och i värsta fall kan mätningen i sig begränsa prestanda. Mäter man för lite kan man behöva göra omtester för att identifiera underliggande fel från ett övergripande mätetal.

•

Vilka icke-klientsides-mätetal kan vara relevanta? CPU? Minne? I/O? Trådhantering? Throughput? Garbage collect? Mera?Mäter man för mycket är det svårt att identifiera flaskhalsar, och i värsta fall kan mätningen i sig begränsa prestanda. Mäter man för lite kan man behöva göra omtester för att identifiera underliggande fel från ett övergripande mätetal.

•

Monitoreras lastgeneratorerna så att man inte behöver vara orolig att de inte förmår leverera den last man tror?Om begränsningen ligger i lastgeneratorerna får man en falsk trygghet när man tror att ett system klarar en viss last.

•

Avser man parallellt använda en probing client - alltså en manuellt hanterad klient för att "känna" på upplevd prestanda under last?Ibland ger transaktionstätheten inte ett tillräckligt bra mått. En del webbsidor laddas t.ex. dynamiskt och användaren märker inte om den laddas långsamt.

Checklista för workshop kring prestanda- och kapacitetsrisker (eventuellt prestandatest)