Lastbalansering och Lasttest
Förord
Lastbalansering med fokus på Lasttest. Vilka förutsättningar avgör när lasttest ska genomföras? Hur ska jag genomföra lasttest? Varför behöver jag lasttesta?
Lastbalansering
Lastbalansering handlar om att dela upp arbeten eller processer mellan olika ekvivalenta resurser. I stort är tekniken till för att öka tillgängligheten och minimera svarstiderna för exempelvis en webbserver. En vanlig lösning är att använda sig av ett en servermjukvara som lyssnar på inkommande trafik som därefter vidarebefordrar trafiken till en av de webbservrar som finns i bakgrunden. Trafiken från svarande webbserver vidarebefordras återigen av mjukvaran till klienten. Det innebär att klienten inte kan se eller vet vilken webbserver som svara på förfrågan från klienten. I sig kan detta innebära en ökad säkerhet mot olaga intrång eller felaktigt utnyttjande av webbplatsens tjänster. [Wikipedia1] En alternativ lösning, Round Robin DNS, utgår ifrån att ha flera IP-adresser kopplande till samma URL. Klienten kan i det här fallet se vilka olika IP-adresser som används för just detta domännamn. Säkerheten minskar, men du behöver inte använda en servermjukvara. Ett problem med denna lösning är att trafiken inte styrs och att en webbserver kan tvingas till att ta hand om all trafik eftersom vissa webbläsare sparar IP-adressen lokalt och inte gör nya sökningar på domännamn varje gång. Säkerheten är också lägre eftersom den aktuella webbadressen kan spåras av kunniga användare. [Wikipedia1]
Round Robin DNS
Round Robin DNS är i sin enklaste form ett trubbigt instrument som helt enkelt distribuerar anrop och svar från IP-adresser utifrån en på förhand definierad lista. Om webbplatsen försörjs av tre olika webbservrar skulle anropen exekveras enligt följande lista: [Wikipedia2]
- Anrop 1 - Webbserver 1
- Anrop 2 - Webbserver 2
- Anrop 3 - Webbserver 3
- Anrop 4 - Webbserver 1
- och så vidare
Lasttest
Lasttest är ett sätt att testa olika mjukvarusystem för hög belastning. Det kan avse ordbehandlare, affärssystem eller webbserver i klient/server- modellen. Själva idén med ett lasttest är att se hur väl ett system klarar hög belastning antingen genom att låta ordbehandlaren öppna ett mycket stort dokument eller för ett Affärssystem att generera en rapport som sträcker sig över flera år. För en webbserver handlar det i första hand om att testa om webbservern klarar hög och onormalt många samtidiga användare i syfte att se om beställarens krav är uppfyllda. Däremot om tester görs för att överbelasta systemet i syfte att leverera den typ av last som systemet inte klarar av är det frågan om ett stresstest. [Wikipedia3]
Nivå av lasttest
I normalfallet är två olika typer av lasttest intressanta, tillgänglighet och svarstid. Tillgänglighet beskrivs i termer av hur ofta det går att nå webbservern, d v s om den är online eller inte. Beroende på verksamhet är det olika kritiskt för företag, institutioner och myndigheter hur tillgänglig webbservern är och vid vilka tidpunkter. En nätmäklare har väldefinierade krav på tillgänglighet där en kommunal hemsida inte är riktigt lika kritisk. [Menascé]
Svarstid är den tid det tar för användaren att begära en sida från en webbserver till dess att hela sidan laddats upp till klienten. Här spelar många faktorer in som exempelvis sidans innehåll, bandbredden på serversidan, bandbredden på klientsidan, hopcount samt tredjepartsinnehåll i form av reklam och dylikt. Sidans innehåll går att påverka genom att skala bilder rätt, använda rätt form av bilder så sidorna blir så små som möjligt utan att göra avkall på användbarhet. [Menascé]
Genomförande av lasttest
Att mäta tillgänglighet är förhållandevis enkelt och kräver egentligen bara en logga på när servern svarar på anrop, med exempelvis ping. Enkelt mätbart och ett tydligt krav från beställaren är lätt att mäta. [Menascé] Svarstider är svårare att genomföra och kräver eftertanke. Förutom att logga riktiga användare i den riktiga miljön kan man använda sig av virtuella användare (agenter) som uppträder som riktiga användare så långt det är möjligt. Det är inte meningsfullt att exempelvis använda bara snabba användare som skickar ny förfrågan efter ett svar, utan har verkliga betänketider innan ny förfrågan levereras till servern. Riktiga användare blir dessutom frustrerade och kan leverera ett 10-tal anrop inom någon sekund om servern svarar allt för långsamt. [Menascé]
Hur irrationellt användaren än agerar är det som agenten ska härma. Användare har också förmåga att lämna webbplatsen om svarstiden blir allt för lång - vilket också ska mätas. Börja gärna med att mäta den verkliga trafiken under lång tid så du får en uppfattning om hur dina användare använder just den här webbplatsen. En bank har exempelvis inte samma besökarmönster som en vädersite. Sannolikt är belastningen på en bank oerhört mycket högre de sista dagarna i månaden, gärna kvällstid, då kunderna ska signera sina räkningar, flytta medel mellan konton och förbereda månadens e-fakturastorm. [Menascé]
Ta också hänsyn till att göra relativt omfattande tester, vid olika tidpunkter och olika dagar. Att bara testa en kortare tid vid ett tillfälle säger egentligen ingenting (även om en gång är bättre än ingen gång). Ju bättre du lyckas fånga dina användares beteenden under längre tid och ju längre tester du genomför desto mer trovärdigt ät resultatet. [Menascé]
När ska lasttest användas?
Egentligen en svår fråga att besvara, men överväg det som kan förändra trafiken på webbservern. - Genomförs en reklamkampanj, som många nya användare kan attraheras av?
- Kommer infrastrukturen att genomgå omfattande ändringar?
- Kommer vi att införa nya tekniker (flash och silverlight) som väsentligt gör webbplatsens material större, vilket kan påverka mängden utgående trafik? Eller, för en e-handelsplats riktad till konsumenter, börjar det närma sig jul?
Alla dessa och fler frågor bör man ta i beaktande - och det räcker med ett ja-svar för att genomföra en lasttest.
Resultat av lasttest
Resultatet av lasttest kan delas upp i tre huvudparametrar: intensitet (sessionsstarter per timme); mix (användarnas surfvanor) samt beteende. Intensiteten är den parameter som sätter nivån på antalet användare, eller det vi normalt kallar hitcount. I normalfallet försöker webbsidor mäta antalet unika användare - vilket inte är fallet här utan snarare antalet gånger som (ingångs)sidan laddas.
För mixen är vi mer intresserade av vad olika användartyper gör när de är på vår site. Antingen är dem ute efter att kolla priset på en viss vara, strösurfar för att hitta något som passar eller faktiskt beställa varan. Användarbeteendet kan som bekant variera. Det är lika många som surfar runt på webbplatser för att välja vara och sen går ut och köper den i butik, som de som kollar priset i en butik - för att sedan beställa varan på nätet.
Användarnas beteende ska mätas i förhållande till sessionsstarter. Här gäller det att ha koll på tröskelvärden för användare att ge upp sessionen, betänketid och den typen av beteenden. Glöm inte bort att det är människor som surfar, som faktiskt inte matar ur sig kommandon så fort en sida är färdigladdad.
Källhänvisning
[Wikipedia1] Load balancing. (2008-11-24). http://en.wikipedia.org/wiki/Load_balancing_(computing). [Wikipedia2] Round Robin DNS. (2008-11-28). http://en.wikipedia.org/wiki/Round_robin.
[Wikipedia3] Load testing. (2008-11-28). http://en.wikipedia.org/wiki/Load_testing.
[Menascé] Load testing of Web sites. Menascé. Daniel A.. (2002-08). http://cs.gmu.edu/~menasce/papers/IEEE-IC-LoadTesting-July-2002.pdf.
Anders Sundberg
Tycker att artikeln är övergripande och bra som underlag för planering, upplägg och exekvering av tester. Skulle vara intressant att läsa en fortsättning med mer ingående exempel (och instruktioner) av lasttester och företrädesvis med OpenSource verktyg.