1. Stresstest - Räcker det inte med funktionstester?
Apicas erfarenhet visar att många webb-projekt misslyckas med att verifiera stabiliteten vid toppbelastning trots uttömmande testning av funktionella krav. Varför är det så?
Webbprojekt testas mot hundratals, eller tom. tusentals, användningsfall för att säkerställa att funktionella och icke funktionella krav uppfylls. ISPer och hosting-bolag kontrolleras med strikta SLA-krav. Trots detta innebär lanseringen ofta en besvikelse pga. dålig prestanda.
- ”Varför är sajten så långsam?”, eller
- ”Varför går sajten ner vid belastningstoppar?”
Detta blir lätt starten på en ”alla skyller på alla”-diskussion mellan ISP, hosting-bolag, plattformsleverantör, utvecklare och applikationsägare.
Att arbeta med stresstest innebär ett nytt och strukturerat angreppssätt för webbprestanda:
- Genom stresstest upptäcks flaskhalsar i infrastruktur och applikationer innan lansering.
- Kapacitetsplanering baseras på produktionsmiljöns prestanda, vilket leder till optimal infrastruktur gentemot applikation och lastscenarion.
2. Apan och provröret
Ibland skämtar vi och säger att låta bli att använda stresstest är som att äta en medicin som bara testats på en enda schimpans. Inte så smart, eller hur?!
Så här tänker vi:
När du funktionstestar så testar du med en enda användare i testmiljön. Testmiljön är normalt sett en ”nästan exakt” kopia av produktionsmiljön. Precis som schimpansen som har 98% samma DNA som människan. Så att testa med en användare i testmiljön är som att testa en ny medicin på en schimpans. Men nya mediciner släpps inte ut på marknaden innan de testats kliniskt på tusentals människor.
Därför bör du köra stresstest på dina affärskritiska webbapplikationer med tusentals samtidiga användare i produktionsmiljön.
6. Att stresstestets lastkurva
”Lastkurvan” visar hur svarstiderna varierar när antalet samtidiga användare ökar.
En väl fungerande webbapplikation uppvisar bara små variationer i svarstiden när antalet användare ökar på låga nivåer. Applikation och infrastruktur är väl balanserade och kan absorbera last utan några större variationer i svarstid.
Vid en särskild punkt på kurvan börjar sedan svarstiderna att öka – vi kallar detta för lastkurvans ”knä”.
När svarstiderna ökar, minskar ”throughput”, dvs data som skickas från servrar till användarna, vilket betyder att användarupplevelsen blir en ändlös väntan på timglaset.
I värsta fall slutar sajten att svara helt, svarstiden blir oändlig och throughput blir noll. Detta är en kraschad sajt.
Slutligen, när lasten reduceras är den viktiga frågan om applikationen klarar av att återgå till ett stabilt tillståndeller om den måste startas om.
Grundlig analys av data från ett stresstest kan också avslöja svagheter innan kritiska lastnivåer uppnåtts. Man kan tex. hitta ”spikar” i lastkurvan, vilket betyder att applikationen och /eller infrastrukturen inte är väl balanserade eller dimensionerade vad gäller webbprestanda.
1. Stresstest - Räcker det inte med funktionstester?
Apicas erfarenhet visar att många webb-projekt misslyckas med att verifiera stabiliteten vid toppbelastning trots uttömmande testning av funktionella krav. Varför är det så?
Webbprojekt testas mot hundratals, eller tom. tusentals, användningsfall för att säkerställa att funktionella och icke funktionella krav uppfylls. ISPer och hosting-bolag kontrolleras med strikta SLA-krav. Trots detta innebär lanseringen ofta en besvikelse pga. dålig prestanda.
- ”Varför är sajten så långsam?”, eller
- ”Varför går sajten ner vid belastningstoppar?”
Detta blir lätt starten på en ”alla skyller på alla”-diskussion mellan ISP, hosting-bolag, plattformsleverantör, utvecklare och applikationsägare.
Att arbeta med stresstest innebär ett nytt och strukturerat angreppssätt för webbprestanda:
- Genom stresstest upptäcks flaskhalsar i infrastruktur och applikationer innan lansering.
- Kapacitetsplanering baseras på produktionsmiljöns prestanda, vilket leder till optimal infrastruktur gentemot applikation och lastscenarion.
2. Apan och provröret
Ibland skämtar vi och säger att låta bli att använda stresstest är som att äta en medicin som bara testats på en enda schimpans. Inte så smart, eller hur?!
Så här tänker vi:
När du funktionstestar så testar du med en enda användare i testmiljön. Testmiljön är normalt sett en ”nästan exakt” kopia av produktionsmiljön. Precis som schimpansen som har 98% samma DNA som människan. Så att testa med en användare i testmiljön är som att testa en ny medicin på en schimpans. Men nya mediciner släpps inte ut på marknaden innan de testats kliniskt på tusentals människor.
Därför bör du köra stresstest på dina affärskritiska webbapplikationer med tusentals samtidiga användare i produktionsmiljön.
6. Att stresstestets lastkurva
”Lastkurvan” visar hur svarstiderna varierar när antalet samtidiga användare ökar.
En väl fungerande webbapplikation uppvisar bara små variationer i svarstiden när antalet användare ökar på låga nivåer. Applikation och infrastruktur är väl balanserade och kan absorbera last utan några större variationer i svarstid.
Vid en särskild punkt på kurvan börjar sedan svarstiderna att öka – vi kallar detta för lastkurvans ”knä”.
När svarstiderna ökar, minskar ”throughput”, dvs data som skickas från servrar till användarna, vilket betyder att användarupplevelsen blir en ändlös väntan på timglaset.
I värsta fall slutar sajten att svara helt, svarstiden blir oändlig och throughput blir noll. Detta är en kraschad sajt.
Slutligen, när lasten reduceras är den viktiga frågan om applikationen klarar av att återgå till ett stabilt tillståndeller om den måste startas om.
Grundlig analys av data från ett stresstest kan också avslöja svagheter innan kritiska lastnivåer uppnåtts. Man kan tex. hitta ”spikar” i lastkurvan, vilket betyder att applikationen och /eller infrastrukturen inte är väl balanserade eller dimensionerade vad gäller webbprestanda.