Molnet har sedan länge varit ett av de hetaste diskussionsteman på nätet. Men kan det verkligen ge ett mervärde för prestandatester? Rätt utnyttjat är det ett mycket kraftfullt verktyg som dramatiskt kan sänka kostnaderna och minska tiderna för att få värdefulla resultat. Följ oss i denna artikel hur vi utförde prestandatesterna åt SAS med hjälp av Amazon EC2 och Visual Studio Loadtest.
LIGHTS IN LINE AB har sedan något år tillbaka utfört prestandatester på regelbunden basis åt Scandinavian Airlines (SAS);
– ”Vi kom in i början som ett komplement då SAS sökte en partner som inte bara var en testshop utan även kunde rådgöra och hjälpa SAS med ett mera helhetsgrepp för att höja och säkerställa prestandan för SAS Internet Portal”
säger Christian Gerdes, som varit kundansvarig för SAS sedan starten.– ”Having worked with Lights In In Line 3 times now, I can highly recommend their professional services AND conceptual thinking. Not only have we found a competente partner in generating heavy and realistic production-look-a-like load, but we also gained a strategic partner in analyzing, setting and sizing our farm.”
säger projektledaren Chris Ramsby
Vi har traditionellt genomfört prestandatester direkt mot SAS produktionsmiljöer, under kontrollerade former. Det gjorde SAS till en klockren kandidat att ta steget fullt ut till att nyttja Molnet som lastgenerator under testerna. Tidigare nyttjades LIL’s egna infrastruktur i Stockholm för att generera produktionslik belastning mot SAS portalen.
– Vi saknade dock möjligheten att snabbt och enkelt kunna skala upp lastgenereringskapaciteten vid behov med vår befintliga miljö. Att använda fysiska servrar har sina fördelar, men även sina begränsningar.
Steget ut i molnet
Innan vi kunde lita på molnets stabilitet och kapacitet kände vi att vi behövde göra en ’benchmark’ av molnet i sig, och kunna mäta vad ett antal virtuella agenter kunde generera för volymer innan de i sig själva blev en flaskhals. För att genomföra detta använde vi vår egna hemsida (www.lightsinline.se) som referens, vilken cachas av en webb accelerator här i stockholm. SAS har sina servrar i Köpenhamn och vi tyckte att ett test mot Stockholm skulle hitta eventuell påverkan av nätverket och internet däremellan lika bra.
Första testerna visade på mycket goda resultat, med 4 agenter av High CPU slaget (c1.medium) i Amazon EC2 kunde vi lätt generera 1000 unika webbläsare och användare per agent i molnet. Dessa fyra, med normala betänketider mellan besöken och en lite elakare inställning av att alla var så kallade ”första gångs besökare” genererade vi en bandbredd på totalt 140 Mbit/s samt en belastning av 4000 samtidiga besökare som genererade cirka 96 sidor per sekund, 953 hits per sekund och cirka 16 000 samtidiga TCP anslutningar mot vår accelerator i Stockholm.
Ovan ser ni Key Performance Metrics för prestandatestet vi gjorde från Amazon EC2 mot www.lightsinline.se för att testa av miljön först. Då samtliga anrop mot vår hemsida cachas av en webb accelerator med en mycket snabb direktanslutning till internet (1GBit) blev detta ett bra test för att validera lastgenereringsmiljön eller testriggen. Som synes i resultaten föreligger inga flaskhalsar vid denna last och man ser även under upprampningen av testet (när vi successivt ökar lasten tills vi når målet med 4000 unika användare) att svarstiderna inte förändras med lasten. Tvärtom är de mycket stabila, tiden för en komplett nedladdning av startsidan inklusive alla bilder och resurser ligger i snitt på 0,46 sekunder med en avvikelse på endast 0,02 sekunder till maximala svarstiden för sidan.
Den gröna grafen i bilden ovan som verkar skakig ska vara precis så. Det är effekten av att förändra betänketiden enligt en normal fördelning för att efterlikna mer produktionslika förhållanden. Istället för att varje användare av de 4000 vi simulerar väntar exakt lika länge mellan sidbesöken varieras denna av verktyget genom att variera tiden däremellan. I snitt blir den dock de 45 sekunder som vi vill ha. Eftersom ett mätvärde i grafen är ett genomsnitt för alla 4000 under de senaste 5 sekunderna varierar detta något pga denna normalfördelning.
Verktygen som vi använde i detta fall är Microsofts verktyg för prestandatester, kallat Load test som ingår i Visual Studio Ultimate sviten samt vanliga public Amazon Web Services (AWS) EC2 molnet där man betalar för maskinerna per timme. Vi satte inför dessa tester upp följande miljö i molnet med hjälp av AWS konsolen (ett webbgränsnitt för molnet).
| Typ av maskin | Kapacitet | Syfte | Pris per timme |
| c1.medium | 1.7 GB / 2x 2.5 GHz | Controller + SQL | 2 SEK |
| c1.medium | 1.7 GB / 2x 2.5 GHz | Load Agent 1 | 2 SEK |
| c1.medium | 1.7 GB / 2x 2.5 GHz | Load Agent 2 | 2 SEK |
| c1.medium | 1.7 GB / 2x 2.5 GHz | Load Agent 3 | 2 SEK |
| c1.medium | 1.7 GB / 2x 2.5 GHz | Load Agent 4 | 2 SEK |
Tabellen visar instans typen, dess kapacitet, vad vi använde den till samt timpriset för instansen. Samtliga maskiner är färdiga Windows Server 2008 Datacenter instanser där licenspriset ingår i timpriset. Förutom timkostnaden tillkommer även avgifter för utnyttjad bandbredd, överförda bytes mot nätverk och disk samt lagringskostnader för diskarna (vi valde EBS (Elastic Block Storage) vilket ger bättre I/O performance och persistenta volymer).
Installationen gjorde vi genom en micro instans där vi skapade en volym med MSDN skivorna för Visual Studio och alla service packs mm. Denna delades sedan ut till alla maskinerna ovan så vi kunde installera programvaran. Det hela gick relativt snabbt eftersom operativet redan var installerat av Amazon. Fördelen efter att VS2010 agent installationen är gjort med EBS volymer är att vi sedan kunde spara undan en AMI (Amazon Machine Image) av en agent för att mycket snabbt starta upp flera utan att behöva installera dem efter uppstart. Vi testade med att starta upp 8 nya agent maskiner parallellt med en sådan image, och det tog endast 4 minuter innan alla var uppe och registrerade i controllern redo för lasttester…
Vi hade testriggen uppstartad under cirka 70 timmar, för att hinna med alla tester och analysera resultaten. Agenterna stängde vi ner så fort vi var klara med dem, varvid de slutar kosta pengar. Totala kostnaden för projektet till Amazon slutade på under 1000 SEK inklusive alla kostnader för datatrafik mm.
Succé av prestandatesterna för SAS
Miljön i Amazon fungerade klockrent under testerna vi sedan utförde åt SAS. Eftersom vi redan visste vad testriggen klarade av, kunde vi mycket snabbt dra slutsatser under själva testerna om vad som blev flaskhalsen. På några timmar hade vi utfört en hel del tester som gav värdefulla resultat. Självklart tack vare bra förarbete;
- Samtliga test automatiseringar (skript) tillverkades i förväg. Vi simulerade trafik till samtliga startsidor på SAS för de olika länderna, samt skapade vi ett ”Klicka runt” skript som simulerade besökare som slumpmässigt valde sidor att läsa på deras portal. Vilka sidor det var lät vi en så kallad ”web-crawler” identifiera först, vilken enkelt förklarat går igenom sajten och letar efter länkar som leder till andra sidor. På detta sätt får man en fräsch realistisk blandning av hundratals unika sidbesök till sidor som faktiskt finns på sajten.
- Själva test scenariot som utfördes bestod sedan av en produktionslik mix av startsidor och klicka runt besök, baserat på tidigare uppmätt statistik. Vi simulerade en betänketid på 45 sekunder mellan sidbesöken, samt en korrekt emulerad Internet Explorer cache av resurser på sidorna. Verktyget kommer automatiskt ladda ner alla resurser som inte finns i cachen eller inte får cachas, och 60% av besökarna simulerade så kallade första gångs besökare, dvs de har inga tidigare cachade filer i sina webbläsare. Vi använde dock ett filter som endast laddar ner resurser som finns på samma sajt, för att undvika trafik utanför de servrar som vi ville testa.
- Verktyget simulerade en webbläsare per användare som har maximalt 6 parallella anslutningar per webbläsare till webbservern. Vi ställde även in connection hanteringen till att vara mer produktionslik avseende keep-alive connections och connections i time wait state, eftersom SAS uttryckligen ville ha sina lastdelare och nätverkskomponenter testade.
- Vi gjorde upp en detaljerad testplan där varje körning och varför vi ville göra den var planerad i förväg. Själva testerna utförde vi sedan via telefonkonferans med alla inblandade parter närvarande och framför sina respektive verktyg, både vi på LIL med prestandatesterna och dess resultat, testledare från SAS som höll i taktpinnen samt driftpersonal med tillgång att kunna se vad som händer på nätverket och servrarna. Vi hade även vårt E2E övervakningsverktyg igång som kontinuerligt övervakade övriga delar av SAS applikationerna för att se hur vi påverkade dem.
Slutsats
Utan att gå ner i detaljerade testresultat måste vi säga att vi är mycket nöjda med resultaten samt hur smidigt det fungerade att arbeta med molnet. Den stora fördelen är just att man mycket snabbt får tillgång till den kapacitet som för tillfället behövs under prestandatesterna, och tack vare prismodellen att betala för det man utnyttjar och per timme lyckades vi minska kostnaderna och tidsåtgång för ett genomfört prestandatest, utan att behöva tumma på kvaliteten.
Vi var initialt oroliga över hur mycket just nätverket mellan Amazon och mål miljön kunde påverka, men tack vare våra möjligheter att kunna validera testriggen först på det sätt vi gjort här visade att vi inte hade något att oroa oss för, och gav oss de mätvärden vi behövde för att kunna dra rätt slutsatser snabbt. Vi kommer fortsättningsvis alltid inleda våra prestandatester med en baseline mot vår egen hemsida som referens.
