Brugerprofil
Hvad besøgende gør og i hvilket forhold: kigger i kataloget, søger, lægger i kurv, betaler med MobilePay eller kort.
Vi finder ud af på forhånd, hvad der sker på Black Friday, efter et stort nyhedsbrev eller når tilmeldingen til et kommunalt tilbud åbner. Et system, der kører fint med ti samtidige brugere, bliver ofte ikke bare langsomt ved tusind, men holder helt op med at svare.
Testen bygger på en realistisk profil af, hvad brugerne gør, ikke på et abstrakt antal samtidige forbindelser.
Hvad besøgende gør og i hvilket forhold: kigger i kataloget, søger, lægger i kurv, betaler med MobilePay eller kort.
Scripts i fx k6, JMeter eller Gatling, der efterligner rigtig adfærd med naturlige pauser mellem handlingerne.
Vi øger trafikken gradvist og registrerer, hvornår svartiden begynder at stige.
Vi finder ud af, hvad der rammer loftet først: CPU, hukommelse, disk, database eller en ekstern tjeneste.
Hvordan systemet opfører sig efter bristepunktet, og om det kommer på benene af sig selv.
Hvad der skal justeres, omskrives eller skaleres, og i hvilken rækkefølge.
Forberedelsen af scripts tager nogle dage. Selve kørslerne er hurtige og gentages efter hver forbedring. Belastningen genereres fra skyen, så intet skal installeres hos jer.
Hvilken belastning skal systemet klare, og med hvilken svartid. Uden konkrete tal er der intet at teste imod.
Separat testmiljø, scripts og en datamængde, der svarer til produktion.
Vi øger belastningen trinvist og måler på hvert trin.
Rapport med fundne flaskehalse og en prioriteret plan for udbedring.
Eksterne tjenester giver typisk op før jeres eget system. Betalingsgatewayen, fragtmodulet eller mailtjenesten har deres egne grænser for antal kald. I testen skal de enten være med eller erstattes ærligt med stubs, og det skal fremgå af konklusionen.
Det frarådes kraftigt: testen kan gøre den utilgængelig for rigtige kunder og forurene statistikken. Det rigtige er en kopi i et separat miljø. Findes den ikke, tester vi om natten, med begrænsning og efter aftale.
Spidsbelastningen med to til tre gange margin, ikke gennemsnittet. Den gennemsnitlige trafik siger næsten intet: belastningen kommer i stød efter en kampagne, en annonce eller omtale i medierne.
Rækkefølgen er som regel: først caching og optimering af databaseforespørgsler, det er billigst og giver ofte flere gange så meget kapacitet. Mere hardware i skyen kommer bagefter, og ændringer i arkitekturen til sidst.
Ja, i de fleste tilfælde. Mange udbydere og CDN'er opfatter pludselig massiv trafik som et angreb. Vi hjælper med at varsle og koordinere tidspunktet.
Skriv den forventede trafik og jeres deadline. Vi simulerer belastningen og viser, hvor problemerne starter.
Tak for jeres henvendelse
Den ligger nu hos en af vores konsulenter. I hører fra os inden for arbejdsdagen, og hastesager bliver taget op af en tekniker med det samme.
Byen står ikke på listen. Tjek stavemåden, eller vælg den nærmeste større by.