SAS gör prestandatester från molnet

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.

Baseline prestandatest mot www.lightsinline.se

Baseline prestandatest mot www.lightsinline.se från Amazon EC2 i Irland

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.

Prestandatest i kombination med övervakning

Vi ser i tidningarnas exempel på rubriker, ”långa svarstider på företag  x webbplats”, ”företag y webbplats kraschade klarade, inte av belastningen”

Rubrikerna skulle inte finnas om företagen kontinuerligt utförde prestandatester samt applikatorisk– och belastningsövervakning. De skulle veta prestandan, veta svarstiderna utifrån användarens perspektiv och samtidigt veta hur många användare som använt applikationen under ett intervall. Och framför allt de skulle med denna information snabbare kunna agera för att förbättra svarstiderna.

En del företag utför enbart en eller max 2 av ovan nämnda processer och det är naturligtvis bättre än inget alls.

Hur ser det ut på ditt företag/organisation ?

Visar med några exempel fördelen av att ha alla 3 processerna på plats, att inte utföra någon av processerna är naturligtvis det sämsta.

Exempel 1:  Du utför enbart Prestandatest
Vid dina kontinuerliga prestandatester vet du att din applikation klarar av 500 användare som under en timme utför 2000 ärenden och svarstiden utifrån användarens perspektiv är högst 3 sek. Bra !

Dock, dina användare klagar på att svarstiderna är långa! Utan applikatorisk övervakning och belastningsövervakning vet du inte vad svarstiderna egentligen varit, samt när dessa var dåliga och du vet inte hur många ärenden som utfördes under den värsta timmen eller hur många användare som utfört dessa.

Exempel 2: Du utför enbart applikatorisk övervakning
Du vet att svarstiderna ofta blir över 3 sekunder. Bra med denna koll ! Dock, eftersom prestandatest inte utförts vet du inte hur många användares/antal ärenden som applikationen klarar av. Och du vet inte hur många ärenden som användarna registrerade.

Exempel 3: Du utför enbart belastningsövervakning.
Du vet att 700 användare utfört under en timme utfört 3000 ärenden. Bra ! Dock,  du vet inte svarstiderna vid detta tillfälle eftersom applikatorisk övervakning saknas och du vet inte heller hur mycket svarstiderna borde vara eftersom prestandatester inte utförts.

Exempel 4: Grattis du utför prestandatester, applikatorisk- och belastningsövervakning!
Du vet att din applikation klarar av 500 användare som under en timme utför 2000 ärenden och att svarstiden utifrån användarens perspektiv är 3 sek.
Du vet att svarstiderna är 5 sekunder under vissa perioder och när det inträffar så har du över 700 användare som utför över 3000 ärenden per timme.

Invändningarna mot att inte utföra alla processerna brukar vara, vi har inte tid, tar för mycket resurser från oss, det är dyrt, etc etc

Ovan nämnda processer kan du köpa som tjänster numera, vilket innebär minimum av egen insats, samtidigt som du får koll och ett fast pris per månad.

Vi på Lights In Line AB har mycket lång erfarenhet inom alla branscher att hjälpa till att införa ovannämnda processer i organisationer.

Kontakta oss för en förutsättningslös diskussion.

 

Prestandatest av Swedbank Mobilbanken 3.0

Senaste uppdateringen för HP Loadrunner 11, kallad Patch 4, innehåller lite godis för oss som testar de nya Web 2.0 sajterna. Bland annat stöd för både GWT och JSON REST applikationer i web protokollet med hjälp av den nya DFE tekniken (Data Format Extensions), nya mobila protokoll och stöd för inspelning direkt på nätverket, nya funktioner i Ajax TruClient, stöd för de senaste webbläsarna och mycket mer.

LIL har haft möjligheten i ett av de senaste projekt på Swedbank att dra nytta av dessa funktioner när vi prestandatestade den nya Mobilbanken 3.0. Vi gjorde även en presentation om projektet och hur vi nyttjade dessa nya tekniker i Loadrunner för HUGS (HP User Group Sweden) för två veckor sedan, vilken var mycket uppskattad. Vi kommer även att hålla den internt för Skatteverket idag under deras prestandatestdag och du kan nu även ta del av den här genom att ladda ner den här;

Länk till presentationen
Prestandatest Mobilbanken 3.0

Microsoft Load Testing Virtual Lab

Microsoft har släppt ett nytt sätt att komma igång med testverktygen i Visual Studio. Du får tillgång till en komplett förinstallerad server i Azure molnet, nyuppstartad bara för dig. Du har tillgång till maskinen via en webbaserad remote desktop session i upp till 3 timmar. En guide startar upp automatiskt som leder dig igenom de olika stegen för att göra prestandatester om du vill, eller så utforskar du verktyget helt på egen hand. Komplett med test applikation och testdata, och du kan prova på allt från manuella tester, GUI tester och prestanda tester samt ASP.NET Profilering under belastning.

Helt klart det smidigaste sättet hittills att testa en ny produkt på eller bara snabbt testa av något i en egen virtuell maskin. Även klockren för utbildningar! Jo, helt kostnadsfritt dessutom!

Följ länken nedan för att få en egen maskin.

http://go.microsoft.com/?linkid=9762338

Prestandatest rapport

 

.
Bakgrund

Under de senaste 15 åren har jag deltagit i ett antal prestandatester och frapperats av den skiftande kvalitén rörande de skriftliga rapporterna av testernas resultat.

Prestandatestare har olika fallenhet för framställan av en prestandatestrapport, detta kan vi inte ändra på.
Min erfarenhet är dock att själva slutrapporten av prestandatesterna i många fall kan förbättras med mycket små medel, se längre ned ”De tio budorden vid framtagning av prestandatestrapport”.

Jag har inte föreslagit en exakt mall om de olika avsnitten i en prestandarapport, här är det de olika omständigheterna som spelar in. Exempelvis är det skillnad på en rapport som tas fram för applikationer som prestandatestas kontinuerligt varje månad jämfört med en applikation som efter flera månaders utvecklingsarbete skall prestandatestas.

En gammal kollega inom prestandatestområdet menade att om du efter ett dygn efter rapportens framställande öppnar den och upplever ljuv musik när du läser den, då vet du att mottagaren kommer att få en bra rapport.

Och visst är det så, du ger något till din uppdragsgivare och vet att han/hon kommer att uppskatta rapporten, det kallas yrkesstolthet.

Likheter mellan besiktningsprotokoll av bilar och rapport för prestandatester.

Vissa likheter finns i framtagningen av en besiktningsrapport och prestandatestrapport.

•    Du vill genom kontroll, ok det är lagstadgat :), få reda på konditionen på    din bil.
•    Resultaten är baserade på ett antal tester av de verktyg besiktningsmannen förfogar över.
•    Analysen av resultaten är besiktningsprotokollet.
•    Sammanfattningen, som är muntlig och skriftlig, utgörs av en noggrann skala allt från körförbud till inga anmärkningar.

•    Visst finns det olikheter, rekommendation är väl snarast ersatt med direktiv, exempelvis är körförbud ingen rekommendation utan snarast att betrakta som ett verkställande direktiv :).

De tio budorden vid framtagning av prestandatestrapport

1. Dela upp i tre delar, sammanfattning, analysen av testerna, resultaten av testerna, förklara uppdelningen.

Kommentarer: Förklara i början av rapporten att den är uppdelad på detta sätt. Resultaten av testerna tillsammans med dagbok/kommentarer till testerna finns i kapitlet resultatet av testerna. Analysen, här är det egentliga arbetet att tyda siffrorna från de olika mätarna. Sammanfattningen, här tas resultatet från analysen och jämförs med uppdragsbeskrivningen/målet med prestandatesterna. Observera att det naturligtvis finns flera kapitel i prestandatestrapport, exempelvis avgränsningar, prestandamål, etc. etc.

2. Sammanfattningens resultat skall kunna refereras till vilka analyser som gjordes och som i sin tur till refererar till resultaten av testerna.

Kommentar: Tangerar mycket punkt 1, det skall poängteras att det inte får finnas några lösa referenser. Allt material i rapporten har syfte att vara underlag för sammanfattningen och rekommendation.

3. Resultat i form av grafer/ eller tabeller läggs i kapitlet resultat av testerna.

Kommentar: Om det är en tabell/graf som är oerhört viktig för rekommendationen, lägg en direkt referens till denna och kommentera.

4. Fokusera alltid på uppdragsbeskrivningen, dvs. vad är det uppdragsgivaren vill ha svar på.

Kommentar: Det händer att uppdragsgivaren har angivet exakt vad prestandamålen är, men i de flesta fall ligger snarare uppdragsbeskrivningen att exempelvis ”applikationen skall klara av dagens trafik på webben”. Då är det viktigt att i uppdraget ange på vad detta innebär i prestandamål, detta görs med fördel tillsammans med uppdragsgivaren.

5. En rekommendation skall alltid göras, oavsett storleken på uppdraget.

Kommentar: Du kan och skall alltid ange en rekommendation, jfr med bilprovningen om besiktningsmannen skulle säga jag vet inte…, du har betalat för testen och vet inte vad rekommendationen är .. Däremot kan en rekommendation alltid vara med vissa förbehåll. Jfr med bilprovningen, ”din bil blev godkänd, men det är värt att notera visst glapp i övre styrleden höger sida som du bör åtgärda närmaste tiden”.

6. Stavfel och uppenbar dålig svenska, skall och kan undvikas.

Kommentar; Det är ju uppenbart, en slarvig hopsatt prestandatestrapport ger ett intryck av att kanske testerna också var slarviga. En prestandatestrapport, skall kunna läsas av både tekniker och beslutsfattare som inte är tekniskt lagda. Det finns bra stavningsprogram och lämna gärna till en kollega som får läsa igenom rapporten.

7. Underlaget till prestandatestrapporten består naturligtvis av dokumenterade resultat med kommentarer.

Kommentar: Kanske helt självklart, men ibland dokumenterar vi inte händelser i rapporten, vi tycker att den händelsen visste ju alla om. Och så kommer det direkt i sammanfattningen utan att vi förklarat att just dessa siffror berodde på …

8. Om du vill berätta att det var mycket omkörningar, berätta inte detta genom att ta med diagram som är oväsentliga för resultaten.

Kommentar: Det är inte ovanligt att man efter ett antal prestandatester av olika anledningar finner att testerna utfördes under felaktiga förutsättningar, ex du var inte ensam i målmiljön. Det enda riktiga är att göra om dessa, ta då inte med resultaten av de felaktiga testerna i rapporten. Nämn detta dock i analysen, och ev. även i sammanfattningen.

9. Förklara innebörden i de begrepp du använder.

Kommentar: Allt sedan prestandatester började bli vanliga för IT-system använder prestandatestare ibland olika namn på samma begrepp. Innan vi inom prestandatestsfären fått en sådan ”begreppskalender”, skriv vad du menar med de olika begreppen, använd med fördel referens till en  bilaga av begrepp i din rapport.

10. Blanda inte begreppen, använd samma enheter i rapporten.

Kommentar: Det är lätt hänt att man som prestandatestare blir ”hemmablind” och använder olika namn på samma sak. För den som skall läsa rapporten skapar det onödig förvirring och drar ner betyget.

Samla in svarstider från användarens webbläsare

Det finns i dagsläget många sätt att samla in svarstider för en webbsajt eller webbapplikation. Allt från enkelt och billigt till avancerat och extremt dyrt. En av utmaningarna har även varit att det finns lika många sätt att mäta svarstider på som det finns produkter och tjänster som utför detta.

Först lite bakgrund;

Man kan grovt dela in alla dessa olika sätt att mäta svarstider på i 2 kategorier; Det ena är aktiv mätning, i form av virtuella användare som besöker sajten eller applikationen enligt ett förutbestämt sätt (en testautomatisering). Det andra är passiv mätning, som istället analyserar den trafik och de besök och transaktioner som riktiga användare utför.

Aktiv mätning är ett mycket kraftfullt och enkelt sätt att mäta svarstider och prestanda på i en produktionsmiljö, dels kan vi mäta på exakt samma sätt i drift som vi gjorde under prestandatester (och därmed återanvända skript och jämföra mot resultat), dels kan vi mäta exakt så som vi vill i form av transaktioner och mätpunkter, och vi mäter med regelbundna intervaller vilket underlättar analysen och ger ett jämnt statistiskt underlag. Andra fördelar är att vi kan spara undan snapshots av fel, stacktracar och felmeddelanden och tom hela screenshots (eftersom vi utför tester med förväntade resultat) och spara undan värdefull information och testdata som kan skickas med i larm och felmeddelanden till driftpersonal för att de så snabbt som möjligt kan återskapa felet och åtgärda problemet. Detta är vad tex vår E2E Light tjänst gör.
Det finns dock några nackdelar, vi måste tex ha testdata eller testpersoner i driftmiljön, vilket inte är möjligt för alla. Andra nackdelar när det gäller att mäta prestanda ur ett användarperspektiv, är att vi mäter från ett fåtal punkter och alltid på samma sätt, medan de riktiga besökarna kommer från tusentals olika platser, med många olika förutsättningar som webbläsare, operativsystem, nätverk, enheter mm. En annan nackdel är just testautomatiseringen, vi måste i förväg skapa ett beteende som vi mäter. Vi begränsas av ekonomiska- och tids- skäl till att inte kunna testautomatisera allting som går att göra på en sajt, och dessutom ändrar besökarna eller användarna sitt beteende oftare än sällan.

Passiv mätning har traditionellt varit en större utmaning, och det har till stor del varit på tekniska grunder. Informationen som funnits tillgänglig utan att skapa förutsättningar för detta har fram tills idag endast varit loggar och mätvärden som operativsystem och infrastruktur ger (i form av performance counters och accessloggar). Det finns några olika angreppssätt, där produkter analyserar loggar, nätverkstrafik och vissa produkter t.o.m. kopplar in sig i applikationens kod (en form av profilering) vilket är möjligt på tex .NET eller Java baserade lösningar. Men den stora utmaningen har varit att mappa tillbaks denna information till användarnas beteenden, dvs till en funktion som utförs av en användare, eller under vilka förutsättningar som tex felen inträffar.
Passiv mätning har dock en större potential än aktiv mätning, just för att den potentiellt kan mäta allt som sker på sajten och kan även mäta själva beteendet av användarna på sajten. Vissa applikationer som utvecklas har dock välsignats med en arkitekt som tänkt på detta i förväg, och som skapar en mätbar applikation, som loggar eller tillhandahåller mätvärden som visar hur många användare som gör vad, hur lång tid det tar och hur ofta vad går fel. Har man dessutom valt att publicera denna data med ett standardiserat sätt, som Performance Counters, WMI, JMX, SNMP eller något annat API, finns det flertalet övervakningslösningar som kan samla in och trendanalysera detta. Alla dessa alternativ kan även användas under prestandatester för att mäta och analysera detta proaktivt innan drift.

På senare tid har passiv mätning även förflyttats till klienterna, för att kunna mäta beteendet av användarna på sajten. Detta har gjorts mycket enkelt att införa på webbapplikationer i form av internetbaserade tjänster som tar emot statistiken och trendanalyserar denna. Detta är tjänster som tex Google Analytics, WebTrends och WebTuna. Utmaningen som dessa har haft är dock att det är relativt lätt att mäta beteendet, dvs vad en besökare gör, men mycket svårare att mäta svarstiden. Ännu svårare är det att mäta vad som går fel eller hur ofta något går fel eller slutat att fungera, eftersom dessa tjänster inte känner till det förväntade korrekta svaret och heller inte sparar det svar användaren fick. Det man ser i dessa verktyg är att lasten minskar och vet man med sig att den borde vara högre kan man misstänka att något slutat fungera. Inte bra. Det är nämligen ofta så, att fungerar inte en sida eller sajten, slås den passiva mätfunktionen ofta ut helt och hållet, eftersom den baserar sig på kod och information som finns i svaret från servern. Man kan möjligen se att lasten på felsidorna ökar, om sajten är konstruerad att skicka användaren till en sådan. Men det är om.
När det gäller svarstider för att mäta prestanda har några försök gjorts genom att mäta detta på olika sätt med hjälp av javascript, men det har gett tvivelaktiga och varierande resultat, främst då för att de endast kan mäta en del av renderingstiden, vilket visar tiden att ladda ner sidan samt alla dess delar, som reklam mm. För att kunna analysera ett prestandaproblem i drift, behöver man kunna bryta ner svarstiden för tex DNS, Connect, Response och Network time, så som man även gör under prestandatester eller vid aktiv mätning (se ovan).

Den nya världen

Vad som har hänt nyligen, och som denna artikel egentligen handlar om (efter mycket bakgrundsinformation) är en ny standard i webbläsarna att mäta och tillhandahålla svarstidsinformation i DOM’en. Detta håller på standardiseras av W3C under den s.k. Navigation Timing Specification. Kort och gått specifierar denna att och hur webbläsare ska mäta svarstider för nedladdade sidor (ej individuella resurser) samt hur den ska vara tillgänglig. Det innebär att vem som hellst med ett litet javascript på sidan kan börja mäta svarstiderna som varje användare får, allt från DNS tiden, till anslutningstiden till servern, serverns svarstid samt tiden det tar att ladda sidan över nätverket, tills den slutligen är renderad och klar med alla ingående resurser (som bilder, stylesheets och inlänkad reklam). Denna information använder dels webbläsarna själva, och man kan se den i grafisk form genom de inbyggda utvecklarverktygen som finns. De stora webbläsarna följer redan denna standard (Internet Explorer 9, Firefox 7 och Chrome 6).

Bilden ovan visar ett exempel av hur mätvärdena kan visas i grafisk form av ett javascript på en sida. Bilden kommer från Webtiming Demo på Appspot, vilken i realtid visar vilken svarstid du fick när du besökte sidan och bryter ner den i en bild som ovan. Utan att gräva ner sig djupare i vad man kan göra själv med hjälp av dessa nya tekniker så finns det redan ett par trendanalysverktyg på marknaden som använder denna information från webbläsarna, först ut var WebTuna och snart följde Google Analytics efter, samt har Piwik det i sin roadmap för version 1.8. Om du använder Googles tjänst, hittar du efter inloggning numera en sektion i portalen som heter Site Speed där denna information visas;

Bilden ovan är tagen för en medelstor webbplats i sverige och visar dels Site Speed värdet för Avg. Page download time per dygn senaste månaden samt i samma graf även antalet Page Views för samma dygn. Tabellen nedanför grafen visar samtliga mätvärden för de mest besökta sidorna på sajten (jag klippte endast med de första två). Man ser tydligt i statistiken vilken skillnad det är i page load time versus tex Server response time samt Download time (vilket är de tider som påverkas av prestandan på webbsajten) medans den totala tiden att ladda sidan (Avg Page Load Time) till stor del påverkas av klientens och användarens val av dator, internetanslutning, plugins i webbläsare mm. Grafen i detta fall visar även att svarstiden från servrarna inte påverkas av lasten i form av page views, vilket beror på att på denna sajt har vi hjälpt kunden att sätta upp en webbaccelerator framför webbsidorna (Varnish Webcache). Det är även anledningen till de mycket låga svarstiderna (Connect samt Server Response Time).

Summa summarum, det har hänt en del avseende tekniken för att mäta just svarstider. Den bästa övervakningslösningen kombinerar så klart dessa två element av både aktiv mätning och övervakning för att mäta prestanda samt tillgängligheten på webbsidan, samt passiv mätning för att mäta och trendanalysera beteenden och användarupplevda svarstider. Om denna artikel gjorde dig nyfiken och du vill veta mer eller ha hjälp att komma igång med E2E mätningar, hör av dig till oss så bjuder vi på en god kopp kaffe eller en lunch på vårt kontor samt en inspirerande diskussion 🙂

Skicka ett mail till kontakt@lightsinline.se eller se alternativa kontaktvägar här.

Att prestandatesta en webbsajt

En av utmaningarna med prestandatester av webbsidor är bland mycket annat att korrekt simulera besökarnas beteenden. Inom prestandatest kallar man detta för scenarion och skript, men det är egentligen en anpassad form av testautomatisering. Ett verktyg som utför ett (eller ofta flera) fördefinierat test används för att med automatik enligt ett visst mönster och beteende besöka en webbsida eller en webbapplikation och utföra ett antal moment, som valideras för dess funktionalitet, samt för syftet av prestandatester, mäter vi svarstiden för hur lång tid det tar att utföra dessa moment.

Men till skillnad mot testautomatisering med syfte att validera funktionerna på webbplatsen är syftet under prestandatester att på något sätt simulera riktiga besökare, och här blir det ofta lite klurigt. För vad gör de riktiga besökarna på webbsidan egentligen?

Här kan man nyttja dels de analysverktyg som finns tillgängliga, som tex genom att analysera webbserverns access loggar. I dessa loggas vad varje användare har hämtat ner för resurser från vår webbserver. Men för att få ut nånting vettigt av dessa, som svarstider eller i vilken ordning vilka sidor besöks oftast, måste vi slå på ganska mycket extra loggning vilket i sin tur kan slöa ner webbservern, då det kostar en del CPU och disk IO att logga allt detta. Som alternativ finns då några gratis tjänster på nätet man kan använda, som via ett enkelt litet javascipt loggar besökarnas trender till ett separat webbsystem. Google Analytics är ett exempel på dessa.

Men prestandatester vill man ju göra innan man går live med en ny sajt, så vad får man ut av detta då? Man kan ju önska att alla som redan är i drift med sina sajter kunde dela med sig lite av sin statistik. Just detta försöker Google åstadkomma. Jag fick nyligen en första rapport av Google, där de även hade jämfört trenderna för 2010 och 2011, vilket pekar på några intressanta resultat;

2010 2011 Diff
Pages/Visit 4,9 4,5 -0,4
Bounce Rate 48.2% 47.0% -1,20%
Avg. Time on Site 05:49 05:23 -0:26
Think Time (s) 71,22 71,77 0,55

Tabellen visar några intressanta mätvärden som vi har nytta av under prestandatester av en sajt vilka vi får från statistikverktyget. En första anblick säger att skillnaden mellan just 2010 och 2011 inte är så stora, och det ger lite mera tyngd för att kunna använda dessa data som en form av baseline för andra sajter. Värdena ovan är genomsnitt för alla sajter på Google Analytics vilka deltar i Shared Data programmet (ett antal hundra tusen i dagsläget).

De första 3 värderna kommer direkt från Google Analytics och det fjärde, Think Time har vi räknat fram genom att dela totala tiden på sajten med antalet sidor som har besökts.

Det första värdet Pages per visit visar i snitt hur många sidbesök vi bör genomföra per iteration av ett skript under våra tester. Det andra, Bounce Rate visar hur ofta en besökare endast laddar ner en enda sida (oftast en artikel eller startsidan) och sedan lämnar sajten.  Detta inträffar mer frekvent på sajter som låter sig indexeras, och är oftast ett besök på endast startsidan, men kan även vara en besökare som hittat en sida som sökresultat på tex Google eller Bing och läser endast den hittade sidan. En bounce är mycket tyngre i det avseendet att det ofta leder till en så kallad complete page download (inget är cachat i webbläsaren) samt att det i vissa fall kan vara en slumpmässig vald sida eller artikel på sajten (dvs webservern har den troligen inte i sin cache heller utan måste läsa från disk). Detta mäts såklart också under så kallad ”Referrer statistics” där vi ser hur besökare hittar till sajten. ”Direct” innebär att de mer eller mindre knappade in adressen i webbläsaren eller har ett bokmärke och därmed hamnar troligen på startsidan. Kommer de däremot från Google eller Bing är det via en sökning.

Dessa olika beteenden simulerar man enklast med 2 olika skript, det ena som simulerar bounce rate (tex startsidan och/eller 1 slumpmässig sida) och det andra som simulerar i snitt 4,5 sidbesök. Enligt statistiken ovan för 2011 ska då alltså cirka 47% köra vårt bounce rate skript och resterande vårt klicka runt skript (med i snitt 4,5 sidor). Hur besöker man då 0,5 sidor? Jo, varannan gång. Alternativt gör vi två skript av detta med, ett med 3 sidor och ett med 6 sidor som körs av lika många användare (3+6)/2 = 4,5.

Average Time on site samt framför allt Think Time är viktiga parametrar då dessa är nödvändiga att specifiera i ett prestandatest, då detta återspeglar den simulerade betänketiden som vi ska ha mellan klick eller sidbyten i ett skript. Självklart varierar detta rejält från besökare till besökare, och därför kan de flesta verktyg utföra en normalfördelning eller en slumpmässig variation på denna betänketid för att på så sätt även simulera spikar/toppar och dalar under testet.

Vi kan även använda denna betänketid för att transformera andra mätvärden som ett prestandatestverktyg samlar in. Tex mäter man ofta lasten som genereras under ett test i form av Sidor per sekund som laddas ner av virtuella användare. Om vi tex under ett test påvisar att en webbapplikation klarar som max 160 sidor per sekund innan tex nätverket eller CPU blir en flaskhals, kan vi alltså räkna fram ett besökarantal som skulle krävas för att generera denna last, nämligen 160 * betänketiden (vilket med snittvärdet för 2011 ovan innebär 11 483 samtidiga besökare).

72 sekunder betänketid kan tyckas vara en hög siffra, och denna varierar så klart från användare till användare (första gångs besökare, ovana och vana besökare mm) samt även sajtens struktur och design. Ju mer det finns att läsa och begrunda på en sida, ju högre blir betänketiden. En webbapplikation för aktiehandel eller en internetbank kommer tex att ha ett annat mönster (tex neråt 45-50 sekunder) än tex ett digitalt magasin eller en tidning.

Slutligen, nu när vi vet ungefär hur många besökare och hur ofta de gör något på en sajt, återstår att spegla vad de faktiskt tittar på eller gör på en sajt. Är sajten redan i drift eller kanske en äldre version av sajten är det, kan verktyg som Google Analytics såklart även visa hur ofta besökare gör vad på sajten. Det var det ursprungliga syftet med dessa verktyg. Har man inte tillgång till detta, kan man ändå använda genomsnitts statistik, som bounce rate ovan, för att bygga ett rimligt mönster. Det är inte ovanligt att startsidan på en sajt står för över hälften av alla sidbesök. För att sedan fylla på med ytterligare 3,5 klick (för att komma upp i 4,5) så får man leka lite beteendevetare, och titta på startsidan och bedömma vad som kan vara rimligt.

Avslutningsvist listar jag några alternativa produkter till Google Analytics;

WebTrends (http://webtrends.com/) är en av de marknadsledande produkterna som man kör helt och hållet själv, antingen direkt på webbservern eller på en separat server. Allt insamlat data behålls därmed in den egna infrastrukturen. Banker, försäkringsbolag och statliga myndigheter använder ofta en sådan lösning då den även har mycket kraftfulla funktioner för att kunna anpassas till sin egna webbapplikation, för att tex mäta User Stories eller Användningsfall istället för endast sidorna.

Ett opensource alternativ till WebTrends och Google Analytics är Piwik (http://piwik.org/) vilken man liksom WebTrends driftar själv och har därmed full tillgång till datat och integrationer men även källkoden för att kunna göra anpassningar.

Slutligen finns det även produkter som inte kräver en javascript kod på websidan (vilket de ovannämnda gör) utan ger sig på webbloggarna på servern istället. Några sådana är tex opensource baserade webalizer (http://www.mrunix.net/webalizer/) samt Windows programmet Web Log Expert (http://www.weblogexpert.com/) vilken även har bra stöd för att skapa egna filter och analyser av beteenden och de vanligaste flöden som besökare genomför.

Förutom dessa finns det en uppsjö av liknande produkter och färdiga tjänster på internet och många CMS leveratörer tillhandahåller även en egen anpassad sådan till sina produkter.

En av nyheterna i de nya webbläsarna (IE9 och FF9) är att javascript numera även kan komma åt svarstider, både DNS tid, nätverk, server svarstider samt renderingstider på ett standardiserat sätt. Några av de större analysverktygen som Google Analytics och WebTuna har redan börjat använda dessa mätvärden i sina tjänster. Men det förtjänar en egen artikel som kommer snart!

Uppdatering: Artikeln är nu skriven och heter Samla in svarstider från användarens webbläsare.

Prestandatest förberedelser faktainsamling

En viktig framgångsfaktor vid genomförande av prestandatest är förberedelserna inför testerna. Oftast är det kort kalendertid mellan beställning och önskat genomförande. Vissa processer, som exempelvis beställning av testdata, evt vpn-inloggningar, korrigeringar i brandväggar, identifiera nyckelpersonal som kan nätverket etc etc, tar viss kalendertid att klara av.

Vi på Lights In Line AB utför hundratals prestandatester årligen och har tagit fram ett dokument , Prestandatest förberedelser,  som vi ofta använder som mall i dialogen med uppdragsgivaren av prestandatestet.

Prestandatest av regalskeppet Wasa

Låt oss göra en resa tillbaka för ca 400 år sedan och se vad som hänt OM regalskeppet Wasa hade prestandatestats.

Landets Industriella Lastämbete, kallat LIL, hade tagit kontakt med Gustav  II och föreslagit en prestanda och stabilitetstest  av skeppet innan jungfrufärden.

Gustav var till en början skeptisk till förslaget, alla hans experter/konstruktörer bedyrade att man hade koll på läget och att tester skulle försinka sjösättningen,  men efter ett par dagars diskussioner med sina skeppsbyggare/ övriga båtvarv så beordrade han en prestandatest, argumenten var bl.a. :

  •  Visserligen skulle det kosta lite mer i början, men det skulle sättas i relation till kostnad/prestigeförlust om Wasa sjösattes och därefter sjönk.
  •  Ju tidigare man upptäckte några defekter desto billigare att åtgärda.
  •  Den skeppsmodell som måste byggas skulle efterlikna det riktiga skeppet Wasa så mycket som möjligt
  •  Gustav kunde få relativt säkra indikationer på hur ändringarna skulle påverka  Wasas sjöegenskaper, detta genom att först utföra ändringarna på skeppsmodellen.

Sagt och gjort, LIL hade alltså från högsta håll fått rollen att utföra prestandatester och när Gustav ville se konsekvenserna av att bygga ut med  flera kanonrader så utfördes denna simulering först på skeppsmodellen.

Resultatet av prestandatesterna  visade under  kapitel sammanfattning,  att konsekvenserna av denna ändring skulle innebära att skeppet skulle kantra för vindstyrkor över 10 meter/sekund. Gustav, som bara orkade läsa denna sammanfattning, kallade genast in sina egna experter som granskade den tekniska delen i rapporten.

Man fann testerna, som utförts för skeppsmodellen, bra dokumenterade och att det enligt framräknade siffror skulle stämma att skeppet skulle kantra.

I rapporten stod det också, att om Gustav ville ha den där extra kanonraden, så rekommenderade LIL att kölsvinet skulle göras djupare för att bereda plats för 40 ton extra bly och därmed höja stabiliteten.

Beslut togs att dessa ändringar först skulle utföras i på skeppsmodellen och därefter testas.

Efter ett par dagar hade tester utförts och i kompletterande prestandarapport stod det att nu var det ingen risk att skeppet skull kantra men prestanda var bedrövlig, farten i båten var ca 6 sekunder för 10m. Om Gustav önskade prestanda 2 sekunder för 10m så krävdes en uppgradering av segelytan med 20% kvadratmeter extra segel.

Gustav beordrade skeppsbyggarna att följa rekommendationerna i rapporten och skeppet sjösattes. Vid stabilitetstesten (30 personer sprang fram och tillbaka tvärskepps) så visade det sig att skeppet ändå var instabilt.

Hur kunde detta vara möjligt, man hade ju följt rekommendationerna från rapporten?

Efter många dagars letande så kom man på orsaken. Man hade enbart lagt 10 ton bly i kölsvinet istället för stipulerade 40 ton. Orsaken till denna fadäs var stressen på hela byggteamet, man hade helt enkelt glömt bort det!

När blyet väl hade kommit på plats riggades fartyget och jungfrufärden ut igenom Stockholm blev en stor triumf. Skeppet Wasa var i kronans tjänst i många år och var väldigt framgångsrikt i de stora sjöslagen.

Gustav var mycket nöjd och införde konceptet prestandatest på alla båtar som byggdes av kronan.

– – – – – – – – – – – – – – – – – –

 

Idag händer det att webbplatser sjösätts och kantar vid många besök.

Kontakta Lights In Line och vi kan hjälpa dig med prestandatest av din webbplats.

 

Prestandatest och SLA

Inledning.

SLA (service level agreement) är ofta med som paragraf i avtal mellan leverantör och kund avseende leverans av IT-tjänster.

Men hur ofta går man igenom i avtalet och kollar hur väl det uppfylls?, Och hur många gånger är leverantören och kunden överens om vad som skall mätas och vad stipulerade siffror står för? Och vem skall mäta detta, leverantören?

Med rätt metodik och processer genererar en SLA överenskommelse/avtal att leverantören och kunden under avtalets gång har full koll på hur pass väl leverantören uppfyller avtalet/överenskommelsen.

Metodiken.

Här beskrivs en väl beprövad metodik som vi på Lights In Line AB hjälper våra kunder att komma igång med.

  • Överenskommelse och beskrivning av processerna
  • Avtal mellan kund och leverantör
  • Processen uppföljning

Överenskommelse och beskrivning.

I detta dokument beskrivs vilka processer som behövs för att exempelvis kunna mäta svarstider och tillgänglighet på IT-systemet. Beskrivning av när prestandatest skall ske och vilka parametrar som skall användas. Se vidare LIL SLA Exempel överenskommelse processerna.

I LIL SLA Processerna visas processerna översiktligt.

Avtal mellan kund och leverantör.

När kunden och leverantören är överens om vad som förväntas av respektive part är det dags att skriva avtalet och exempel på ett sådant är LIL SLA Exempel avtal.

Processen uppföljning.

I denna process följs resultaten av mätningarna i produktion upp. Genom exempelvis en månatlig sammanställning och genomgång av denna så blir det en kontinuitet i kollen på att utlovad SLA levereras. Se LIL SLA uppföljning.

Sammanfattning.

Vi på Lights In Line har sedan många år tillbaka haft förmånen att hjälpa våra kunder med att införa denna metodik och resultatet har blivit högre tillgänglighet på IT-tjänsterna.

Kontakta oss gärna för referenser.