Det indeholder ydelsen

Testen bygger på en realistisk profil af, hvad brugerne gør, ikke på et abstrakt antal samtidige forbindelser.

Drøft omfanget

Brugerprofil

Hvad besøgende gør og i hvilket forhold: kigger i kataloget, søger, lægger i kurv, betaler med MobilePay eller kort.

Scripts

Scripts i fx k6, JMeter eller Gatling, der efterligner rigtig adfærd med naturlige pauser mellem handlingerne.

Optrapning

Vi øger trafikken gradvist og registrerer, hvornår svartiden begynder at stige.

Flaskehals

Vi finder ud af, hvad der rammer loftet først: CPU, hukommelse, disk, database eller en ekstern tjeneste.

Efter grænsen

Hvordan systemet opfører sig efter bristepunktet, og om det kommer på benene af sig selv.

Anbefalinger

Hvad der skal justeres, omskrives eller skaleres, og i hvilken rækkefølge.

Sådan forløber det

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.

01

Mål

Hvilken belastning skal systemet klare, og med hvilken svartid. Uden konkrete tal er der intet at teste imod.

02

Forberedelse

Separat testmiljø, scripts og en datamængde, der svarer til produktion.

03

Kørsler

Vi øger belastningen trinvist og måler på hvert trin.

04

Analyse

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.

Spørgsmål og svar

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.

Lad os presse systemet

Skriv den forventede trafik og jeres deadline. Vi simulerer belastningen og viser, hvor problemerne starter.

Vi arbejder
I hele Danmark via fjernadgang

Vi bruger kun nødvendige cookies, så siden fungerer og husker den by, du har valgt. Læs mere i vores privatlivspolitik.