All you need to know about:

Performance testing

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.

Happy learning, or happy confirmation that you are already skilled.


Table of contents


Introduktion till domänområdet och till workshopen

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:

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.

Begrepp

BegreppBetydelse
KorreleringI 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.
ParameteriseringOm 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.
MonitoreringKontinuerlig övervakning av relevanta mätpunkter på server, applikation, middleware och infrastruktur under last.
AnvändarscenarioDe transaktioner som en simulerad (virtuell) användare av en viss kategori genomför i systemt.
LastscenarioViktad last över en testomgång. Hur skalas användarscenarion upp och ner.
SynkroniseringspunktPunkt i ett lastscenario där de virtuella (simulerade) användarna väntar in varandra. Används mest i samtidighetstester.
Probing clientEn 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.

Saker att tänka på


Index of keywords