Webhotell for trafikktopper – gjør kampanjen rask når det gjelder

En vellykket kampanje kan gi tusen besøk på få minutter. Det er ikke den månedlige datamengden som avgjør om nettsiden holder. Det er hvor mange forespørsler som kommer samtidig, hvor tunge de er, og om database, skjema, betaling og andre tjenester tåler samme topp.

Derfor er «ubegrenset trafikk» ikke et kapasitetsløfte. Det kan bety at leverandøren ikke fakturerer per gigabyte, mens CPU, minne, prosesser, databaseforbindelser og forespørsler fortsatt har grenser.

Kort svar

Før en kampanje bør dere:

1. anslå trafikken i det travleste minuttet
2. beskrive de viktigste brukerreisene
3. finne alle tekniske og kommersielle grenser
4. kjøre en autorisert test med gradvis økende belastning
5. sette tydelige krav til svartid, feilrate og gjennomførte kjøp
6. avtale oppskalering og varsling med leverandørene
7. forberede en enklere reserveopplevelse

En større webhotellpakke er bare riktig tiltak hvis testen viser at flaskehalsen ligger i ressursene pakken faktisk øker.

Gjennomsnittet skjuler toppminuttet

Anta at en kampanje forventes å gi 12 000 besøk på én time. Et jevnt gjennomsnitt er 200 besøk per minutt. Hvis halvparten klikker de første fem minuttene, blir belastningen 1 200 besøk per minutt i denne perioden. En pushmelding eller TV-omtale kan gi en enda skarpere topp.

Bygg estimatet fra kampanjen, ikke fra normaltrafikken:

• antall mottakere eller seere
• forventet andel som klikker
• hvor konsentrert klikkene kommer
• antall sidevisninger per besøk
• hvor mange dynamiske kall hver brukerreise utløser
• hvor mange som sender inn skjema eller betaler
• andel gjentatte forsøk når noe går tregt

En enkel første beregning er:

Forespørsler per sekund ≈ besøk i toppminuttet × dynamiske forespørsler per besøk ÷ 60

Hvis 1 200 besøk i toppminuttet hver utløser tre dynamiske kall, er utgangspunktet 60 slike forespørsler per sekund. Statiske bilder og stilark kan i stor grad tas av cache eller CDN, men innlogging, lager, handlekurv, betaling og skjema treffer ofte applikasjonen.

Antall samtidige forespørsler avhenger også av svartiden:

Samtidige forespørsler ≈ forespørsler per sekund × gjennomsnittlig varighet i sekunder

Ved 60 forespørsler per sekund og 0,5 sekunders behandlingstid er omtrent 30 forespørsler i arbeid samtidig. Når svartiden stiger til to sekunder, blir samtidigheten omtrent 120 uten at kampanjen har sendt én ekstra bruker. Treghet kan dermed forsterke køen.

Test hele konverteringsløpet

En lasttest som bare åpner forsiden kan bevise at cache fungerer. Den sier lite om kampanjen tjener penger.

Beskriv realistiske brukerreiser med forventet fordeling:

Tallene må tilpasses deres kampanje. Testdata skal ikke sende ekte markedsføring, trekke penger eller forurense produksjonsrapporteringen. Betalingsleverandør, CRM og e-postplattform kan kreve egne testmiljøer.

Kontroller både at svaret kommer raskt og at resultatet er riktig. En server som svarer 200 OK på en feilmelding, er ikke frisk.

Fire tester med forskjellige mål

Røyketest

Kjør noen få brukere for å bekrefte at script, testdata og målinger virker. Dette skal ikke belaste systemet.

Forventet last

Hold beregnet normal kampanjebelastning lenge nok til at cache, database, køer og autoskalering får vist stabil oppførsel.

Topp- eller spiketest

Øk raskt til forventet topp for å etterligne e-postutsendelse, pushvarsel, direktesendt omtale eller billettslipp.

Bruddpunkt og utholdenhet

Øk gradvis for å finne hvor løsningen ikke lenger oppfyller kravene. En lengre test kan vise minnelekkasje, voksende kø, fulle forbindelsespooler eller tregere database.

Grafana k6 beskriver disse som ulike testmål i sin offisielle veiledning for API-lasttesting . Verktøyet støtter både samtidige virtuelle brukere og en fast eller stigende ankomstrate. Velg modell etter om kampanjen skaper bestemte brukergrupper eller en bestemt strøm av handlinger.

Lasttest bare med tillatelse

En lasttest kan ligne et angrep og kan påvirke andre kunder på delt hosting. Avtal skriftlig:

• hvilket miljø og hvilke vertsnavn som skal testes
• dato, klokkeslett og maksimal belastning
• IP-adressene testtrafikken kommer fra
• kontaktperson hos leverandøren
• stoppekriterier
• hvilke tredjepartstjenester som skal erstattes med testdobler
• hvordan testdata slettes etterpå

Start lavt og øk i trinn. Ikke gå rett til forventet maksimum. En test i produksjon krever strengere rammer enn en test i et isolert miljø, men et testmiljø må være representativt nok til at resultatet har verdi.

Sett krav før testen

Uten pass- og feilkriterier blir en lasttest bare en graf. Velg krav som speiler forretningen:

• andel vellykkede forespørsler
• p50, p95 og p99 for svartid
• tid for hele brukerreisen
• andel vellykkede skjemainnsendinger eller betalinger
• ingen dupliserte ordre eller trekk
• maksimal kølengde
• CPU, minne og databaseforbindelser under grense
• akseptabel tid til oppskalering

p95 betyr at 95 prosent av målingene er like raske eller raskere enn verdien. Den avslører en langsom hale som gjennomsnittet kan skjule. Mål samtidig hva brukeren ser i nettleseren og hva backend bruker; det er ulike perspektiver.

Finn den egentlige flaskehalsen

Følg målingene gjennom hele kjeden:

Mer CPU hjelper ikke hvis alle forespørsler venter på én databaseforbindelse. Et CDN hjelper ikke på en ukachet handlekurv. Rask webserver hjelper ikke hvis betalings-API-et avviser for mange kall.

Toppkapasitet og månedlig datatrafikk er separate innkjøpsmål. Bruk båndbreddeguiden til å beregne sidevekt, månedstrafikk og toppminutt før hostinggrensen vurderes.

Bruk cache uten å ødelegge riktige svar

Cache offentlige, like svar der det er forsvarlig:

• landingsside og kampanjeinformasjon
• bilder, stilark og skript med versjonerte filnavn
• produktinformasjon som kan tåle kort forsinkelse
• generelle hjelpesider

Vær forsiktig med:

• innlogging og konto
• handlekurv
• personlig pris eller rabatt
• lager som må være helt ferskt
• bekreftelsessider
• svar som inneholder persondata

Definer hva som skjer ved cachetreff, cachebom og utløp. Forvarm relevante sider hvis løsningen støtter det, men kontroller at testen ikke bare måler en kunstig varm cache. Les hvordan CDN og cache virker før dere endrer regler.

Autoskalering er ikke øyeblikkelig

En plattform kan skalere automatisk og likevel feile under en brå topp. Nye instanser må startes, applikasjonen må bli klar, forbindelser opprettes og cache varmes. Databasen eller en ekstern tjeneste kan fortsatt ha en fast grense.

Spør leverandøren:

1. Hvilke ressurser skalerer automatisk?
2. Hvilke signaler utløser skalering?
3. Hvor lang tid tar den i praksis?
4. Hva er minste og største kapasitet?
5. Må maksimum heves manuelt før kampanjen?
6. Hva koster oppskaleringen?
7. Skaleres databasen, køene og egress samtidig?
8. Hvordan skaleres løsningen ned igjen?

Hvis toppen varer tre minutter og skaleringen bruker fem, må grunnkapasiteten eller en planlagt oppskalering bære starten.

En skyplattform gjør heller ikke applikasjonen skalerbar av seg selv. Sammenlign skyhosting og delt webhotell på ansvar, arkitektur og kostnad hvis automatisk skalering brukes som kjøpsargument.

Planlegg kontrollert degradering

Når alt ikke kan leveres samtidig, bør de viktigste handlingene prioriteres. En plan kan omfatte:

• en enkel, statisk kampanjeside
• kø eller venterom før en knapp ressurs
• ratebegrensning med forståelig tilbakemelding
• midlertidig deaktivering av anbefalinger, video eller tunge søk
• asynkron behandling av e-post og CRM-oppdateringer
• read-only-modus for mindre viktige funksjoner
• tydelig status og nytt forsøk senere

POST-forespørsler for ordre og betaling må være idempotente der det er relevant, slik at brukerens nye forsøk ikke gir doble resultater. Klienten bør ikke hamre løsningen med raske automatiske retries; bruk begrenset forsøk og ventetid.

En reserveside hjelper bare hvis den ikke avhenger av samme database, deploy og origin som feilet.

Kampanjedagen

Før utsendelse

• frys unødvendige deployer og konfigurasjonsendringer
• bekreft at overvåking og varsling virker
• kontroller sertifikat, domene og leverandørstatus
• verifiser planlagt kapasitet og tredjepartsgrenser
• test én ekte brukerreise med kontrollert beløp eller testmodus
• avtal hvem som kan stoppe kampanjen

Under toppen

Følg brukerutfall, ikke bare serverens CPU. Se på feilrate, p95, fullførte kjøp eller skjema, betalingsavvisninger, kø, database og eksterne API-er. Sammenlign med stoppekriteriene.

Ved problemer

Én person leder hendelsen, én følger teknikken og én håndterer kommunikasjon når teamet er stort nok. Aktiver avtalt degradering eller stopp ny trafikk før datakvalitet og ordreintegritet går tapt. Bruk runbooken når nettsiden er nede hvis feilen allerede er synlig.

Etter kampanjen

Behold målinger og tidslinje. Sammenlign prognosen med faktisk topp, finn første metning og oppdater neste test. Kontroller etterslep i e-post, køer, betaling og CRM før beredskapen avsluttes.

Hva betyr konkurrentenes trafikkpåstander?

Opplysningene under er kontrollert 22. august 2026 og må verifiseres på nytt før kjøp.

Uniwebs webhotellside oppgir «ubegrenset datatrafikk», men publiserer også pakker med ulike CPU-, minne-, lagrings- og databasegrenser. Det illustrerer forskjellen mellom overført datamengde og samtidig behandlingskapasitet.

Webadors vilkår sier at det ikke gjelder uttrykkelige maksimumsgrenser for innhold, lagring eller datatrafikk med mindre annet er avtalt, men at leverandøren vil kontakte kunden ved hyppig overdreven bruk. En slik formulering er heller ikke en dokumentert grense for toppbelastning.

Be alltid leverandøren svare for den konkrete kampanjen. Et generelt produktløfte kan ikke erstatte estimat, test og avtalt håndtering.

Hva gjelder for Vymos enkle nettside?

Vymos standardtilbud er én enkel bedriftsside som Vymo setter opp og leverer gjennom Cloudflare. Den er laget for å presentere virksomheten, tjenestene og kontaktinformasjonen uten WordPress, database eller kundestyrt server.

Standardtilbudet publiserer ikke en kapasitetsgaranti, lasttest, automatisk oppskalering, venterom, kampanjeskjema, betalingsflyt eller SLA for trafikktopper. Nettbutikk, booking, innlogging og andre dynamiske funksjoner er ikke inkludert.

En enkel offentlig side kan ha et langt mindre kapasitetsbehov enn en nettbutikk. Skal dere sende en stor kampanje til siden, samle mange innsendinger på kort tid eller ha en bestemt lanseringsdato, må volum, brukerreise og krav avklares med Vymo før kampanjen .

Trenger dere bare en enkel side for vanlig bedriftstrafikk, kan dere se hva den gratis nettsiden inkluderer . Trenger dere dynamisk kapasitet, velg en plattform som dokumenterer og tester den arbeidslasten.

Kravlisten til leverandøren

Send prognosen og be om skriftlige svar:

1. Hvilken ankomstrate og samtidighet støtter den konkrete pakken?
2. Hvilke ressurs- og rategrenser gjelder for hvert lag?
3. Er lasttest tillatt, og under hvilke rammer?
4. Hvordan skalerer løsning og database før og under toppen?
5. Hvilke målinger og varsler får vi tilgang til?
6. Hva skjer når en grense nås?
7. Hvilke tredjepartstjenester må varsles separat?
8. Hvilken hjelp er tilgjengelig mens kampanjen pågår?
9. Hva koster planlagt og automatisk oppskalering?
10. Hvordan ruller vi trygt tilbake etter kampanjen?

Dimensjoner etter handlingene i toppminuttet, ikke sidevisningene i normalmåneden. Da blir kampanjen en inntektsmulighet i stedet for en ufrivillig stresstest.