Tåler nettsiden kampanjen? Kapasitetstest driftsmiljøet før trafikktoppen

En nettside kan fungere utmerket i hverdagen og likevel stoppe opp når en kampanje treffer. Det skyldes ofte at driftsmiljøet er valgt og konfigurert for normal trafikk, mens kapasiteten under samtidige besøk aldri er undersøkt.

Problemet kan vise seg som trege sider, feil i skjemaer, utsolgte varer som fortsatt kan bestilles eller full stans i betalingsflyten. Da hjelper det lite at hostingavtalen lover høy oppetid. Oppetid sier ikke nødvendigvis noe om hvor rask eller brukbar nettsiden er når belastningen øker.

En kapasitetstest gir dere et mer realistisk svar. Målet er ikke å presse serveren til den bryter sammen, men å finne grensene, flaskehalsene og tiltakene før trafikken kommer.

Start med trafikktoppen dere faktisk forventer

Det er lett å be leverandøren om at nettsiden skal tåle «mye trafikk». Det er for upresist til å dimensjonere et driftsmiljø. Belastningen avhenger både av antall besøkende og hva de gjør.

Tusen personer som leser den samme cachede artikkelen, kan være en enkel oppgave. Langt færre brukere som søker, logger inn, filtrerer produkter eller fullfører kjøp, kan gi langt høyere belastning. Slike forespørsler må ofte behandles av applikasjonen og databasen for hver bruker.

Beskriv derfor den forventede toppen konkret:

• Hvor kommer trafikken fra, og hvor raskt forventes den å komme?
• Hvilke landingssider skal de besøkende møte?
• Skal brukerne lese innhold, sende skjema, logge inn eller gjennomføre kjøp?
• Vil mange brukere utføre samme handling samtidig?
• Hvilke eksterne tjenester inngår i brukerreisen?
• Hvor lenge forventes den høye belastningen å vare?

En e-postutsendelse kan skape en brå topp i løpet av få minutter. Søketrafikk etter medieomtale kan bygge seg opp mer gradvis. En kampanje med fast starttid kan sende mange brukere direkte til samme produktside. Disse situasjonene krever forskjellige tester og tiltak.

Skill mellom cachebart og dynamisk innhold

Caching er ofte det mest effektive tiltaket for å håndtere økt trafikk. En ferdig generert side kan leveres uten at publiseringsløsningen og databasen må bygge den på nytt for hvert besøk.

Men ikke alt bør eller kan caches. Handlekurver, kassesider, innloggede områder, personlige priser og enkelte skjemaresultater er dynamiske. Det er derfor misvisende å kapasitetsteste bare forsiden dersom den viktigste brukerreisen ender i en dynamisk løsning.

Test flere lag av caching

Et profesjonelt driftsoppsett kan bruke flere cachelag:

• Nettlesercache reduserer behovet for å laste ned uendrede filer på nytt.
• CDN leverer bilder, stilark, skript og eventuelt hele sider fra servere nærmere brukeren.
• Sidecache lagrer ferdig produserte sider og avlaster applikasjonen.
• Objektcache reduserer gjentatte og kostbare oppslag mot databasen.

Kontroller ikke bare om caching er slått på. Undersøk hvilke sider som faktisk treffes av cachen, hvor lenge innholdet lagres, og hva som skjer når cachen tømmes. En kampanje kan begynne tregt dersom tusenvis av besøk treffer et kaldt cachelag samtidig.

Test også at unntakene er riktige. Feil caching av handlekurv, innlogging eller personlige data kan skape langt mer alvorlige problemer enn treghet.

CDN beskytter ikke hele løsningen

Et CDN kan ta unna mye trafikk og redusere belastningen på den opprinnelige serveren. Det er særlig nyttig for tunge bilder, nedlastbare filer og innhold som er likt for alle. Samtidig kan et CDN skjule svakheter dersom testen bare omfatter cachede sider.

Den opprinnelige serveren må fortsatt håndtere forespørsler som ikke finnes i cachen, dynamiske funksjoner og oppdatering av cacheinnhold. Databasen må behandle søk, ordre og innlogginger. Betalingsløsninger, lagerkoblinger og CRM-integrasjoner kan ha egne kapasitetsgrenser.

Se derfor på hele kjeden. Nettsiden er ikke mer robust enn det svakeste leddet i den viktigste brukerreisen.

Velg driftsmiljø etter konsekvens og variasjon

Riktig driftsmiljø handler ikke bare om hvor mye trafikk dere har i gjennomsnitt. Det handler også om hvor stor variasjonen er, og hva et avbrudd koster.

En administrert plattform kan passe godt når virksomheten ønsker at leverandøren håndterer serveroppsett, sikkerhetsoppdateringer, backup og grunnleggende overvåking. Et mer isolert miljø kan være aktuelt når løsningen har krevende integrasjoner, mye dynamisk trafikk eller behov for tydelig avgrensede ressurser. Skalerbare skyløsninger kan være hensiktsmessige ved store og uforutsigbare topper, men automatisk skalering må konfigureres og testes. Den oppstår ikke av seg selv.

Vurder blant annet:

• Om prosessor, minne og databasekapasitet er delt med andre kunder.
• Hvor raskt kapasiteten kan økes ved behov.
• Om økt kapasitet skjer automatisk eller må bestilles manuelt.
• Hvem som følger med når belastningen øker.
• Om leverandøren har begrensninger på samtidige prosesser eller forespørsler.
• Hvordan kostnadene utvikler seg ved høy trafikk.

Et dyrere miljø er ikke automatisk bedre. En feilkonfigurert løsning med mye kapasitet kan fortsatt være treg. Dimensjonering må kombineres med riktig caching, databasearbeid, vedlikehold og overvåking.

Gjennomfør en realistisk kapasitetstest

Testen bør etterligne ekte bruksmønstre uten å skape unødvendig risiko. Ikke start en tung test mot produksjonsmiljøet uten at driftsleverandøren er informert og har godkjent tidspunktet.

1. Velg kritiske brukerreiser. Test landingssiden, produktsøk, skjema, innlogging eller kjøpsløp ut fra hva kampanjen skal oppnå.
2. Lag et sammenlignbart testmiljø. Serveroppsett, cachelag, database og sentrale integrasjoner bør ligne produksjon. Et lite utviklingsmiljø gir få nyttige svar.
3. Start med normal belastning. Dokumenter responstid, feil og ressursbruk før dere øker trafikken.
4. Øk gradvis. En kontrollert opptrapping gjør det mulig å se når ytelsen begynner å falle, og hvilken komponent som når grensen først.
5. Test både varm og kald cache. Da ser dere forskjellen mellom normal drift og situasjonen etter en tømming eller utrulling.
6. Ta med dynamiske handlinger. Ikke mål bare sidevisninger. Test det brukerne faktisk skal gjøre.
7. Definer stoppkriterier. Avslutt eller reduser testen dersom feilraten, responstiden eller ressursbruken passerer avtalte grenser.

Registrer resultatene på samme måte for hver test. Da kan dere se om en endring faktisk forbedrer kapasiteten, i stedet for å basere beslutningen på magefølelse.

Følg både tekniske og forretningskritiske signaler

Prosessorbruk og minne er nyttige målinger, men de forteller ikke alene om nettsiden fungerer. Under testen og trafikktoppen bør dere også følge med på responstid, databasebelastning, cachetreff, køer, feilmeldinger og tilgjengeligheten til eksterne tjenester.

Kombiner dette med signaler fra brukerreisen:

• Blir skjemaer faktisk sendt inn?
• Kan brukere legge varer i handlekurven?
• Blir betalinger fullført og registrert riktig?
• Oppdateres lagerstatus og ordredata?
• Fungerer kvitteringer og andre automatiske meldinger?

Overvåkingen må ha tydelige mottakere. Avklar hvem som vurderer et varsel, hvem som kan øke kapasiteten, og hvem som kan stanse en kampanje dersom løsningen ikke fungerer forsvarlig.

Beskytt perioden før kampanjen

Unødvendige endringer rett før en trafikktopp øker risikoen. Innfør derfor en kort endringsfrys for programvareoppdateringer, nye integrasjoner og større innholdsendringer. Kritiske sikkerhetsoppdateringer må fortsatt vurderes, men ordinært vedlikehold kan planlegges utenfor den mest utsatte perioden.

Sørg samtidig for at dere har en fersk backup og en kjent prosedyre for gjenoppretting. Backupen bør omfatte både filer, database og nødvendig konfigurasjon. For nettbutikker og andre løsninger med løpende transaksjoner må planen ta høyde for at nye data kan komme inn mellom backup og feil.

Kontroller også sertifikater, lagringsplass, planlagte jobber og eventuelle lisenser som løsningen er avhengig av. Små, oversette driftsoppgaver har en tendens til å bli synlige på verst mulig tidspunkt.

Lag en enkel beslutningsplan for trafikktoppen

Resultatet fra kapasitetstesten bør ende i konkrete beslutninger, ikke bare en rapport. Beskriv hva dere gjør ved ulike tegn på belastning.

• Hvilke funksjoner kan forenkles eller slås av midlertidig?
• Kan tyngre bakgrunnsjobber utsettes?
• Kan mer innhold leveres fra cache eller CDN?
• Når skal serverkapasiteten økes?
• Når skal annonsering, e-post eller annen trafikktilførsel bremses?
• Hvem informerer kunder og interne interessenter ved problemer?

Et mulig tiltak kan være å deaktivere et ressurskrevende anbefalingsfelt før dere påvirker selve kjøpsløpet. Et annet kan være å fordele en utsendelse over lengre tid. Slike valg er enklere å ta når de er diskutert på forhånd.

Kapasitet er en del av den løpende driften

En vellykket test er ikke et varig bevis på at nettsiden tåler all fremtidig trafikk. Innhold, programvare, integrasjoner og bruksmønstre endrer seg. En ny søkefunksjon eller betalingsløsning kan flytte flaskehalsen uten at trafikken øker.

Gjenta derfor relevante deler av testen før store kampanjer, lanseringer og vesentlige tekniske endringer. Sammenlign resultatene med tidligere målinger, og oppdater beslutningsplanen.

Profesjonell webhosting handler ikke bare om å holde serveren på. Driftsmiljøet skal levere de viktigste funksjonene med akseptabel hastighet når virksomheten trenger dem mest. En konkret trafikkbeskrivelse, realistisk kapasitetstest og avklart plan for tiltak gir et langt bedre grunnlag enn å håpe at hostingpakken er stor nok.