Christian Gerdes

Om Christian Gerdes

Grundare och Vice VD för Lights In Line, har bl.a. följande bakrund: "Jag har jobbat med IT och Operations sedan 1997 då jag började på Ericsson med management system för telekomnätverk. Min bakgrund är både från utveckling, tekniskt projektledning och systemadministration och har sedan 2000 jobbat uteslutande med prestanda optimering och teknisk kvalitetssäkring. Jag drivs av att kontinuerligt förbättra processer, metoder och arbetssätt inom det som idag kallas Performance Engineering, och jag håller även en hel del föreläsningar, workshops och utbildningar i ämnet".

Agile DevOps Performance Testing

Lights In Line håller nästa Prestandaforum i Stockholm den 12 Februari 2014 i Spårvagnshallarnas lokaler. Ämnet är Agila Prestandatester och DevOps, och vi kommer gå igenom ett kundcase där vi jobbar hårt med dessa metoder, 25000 VU under 24 timmar och rapport dagen efter. Välkomna!

http://www.meetup.com/Prestandaforum-Stockholm/events/155781162/

Presentationsmaterialet hittar du här: Dev Ops (PDF)

Visual Studio 2013 Loadtest

Ny version av Visual Studio släpptes den 17 Oktober 2013 och det har kommit några trevliga nyheter för oss prestandatestare. I takt med att jag upptäcker dem, samt mina erfarenheter av installationen, så uppdaterar jag denna artikel.

Först och främst är installationen mycket enkel som vanligt. Jag valde denna gång web installationen istället för att ladda ner hela DVDn från MSDN, eftersom det blir mindre att ladda ner då. Installationen jag gjorde var på en ren Windows 8.1 klient PC.

Första frågan efter installationen var ett välja tema. VS2012 är ju väldigt vitt, och man kan hitta tillägg för att ändra färgerna, men nu finns detta alltså inbyggt från början. Trevligt att nu kunna köra prestandatester med VS2013 BLACK EDITION:

VS 2013 Black Edition Load Test

VS 2013 Black Edition Load Test

SQL Server 2012 Express LocalDB

En av nyheterna i VS2013 installationen är att Microsoft nu skeppar med SQL Server 2012 Express LocalDB out of the box. Detta är en special bantad version just för utvecklare, och installeras automatiskt vid första gången någon försöker koppla upp sig till databasen. Det är därmed enkelt att ha flera privata databaser på maskinen, eller per projekt. Det är dock lite svårare att dela dessa med andra, men man kan fortfarande ladda ner SQL 2012 Express och köra denna istället.

LocalDB installeras som default tillsammans med VS2013 Ultimate. Dock konfigurerades denna inte automatiskt efter installationen med LoadTest2010 databasen (Om man inte installerar Visual Studio Loadtest Controller på samma maskin). Detta behöver göras manuellt först innan det går att köra ett loadtest lokalt i VS med databas för resultaten.

LocalDB instansen skapas per automatik första gången den används, och den skapas då i användarens lokala AppData mapp, och ägs även av användaren. Detta är en stor skillnad jämfört med vanliga Express, varje använde på en dator har alltså sin egna resultatdatabas. Det går även enkelt att bifoga ett filnamn till databasen, dvs vart den ska skapas och sparas, vilket gör det möjligt att enkelt skapa nya load test databaser för ett projekt. Varje gång en sådan skapas behöver man dock först skapa LoadTest2010 databasen i denna. Detta görs enklast med följande kommando:

>cd C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE
>sqlcmd -S (localdb)\v11.0 -i loadtestresultsrepository.sql

Det kan ibland ta en stund att skapa databasen, och ge ett timeout felmeddelande, om detta sker så kör sqlcmd kommandot igen med samma argument. Databasen skapas i användarens hemma mapp, och heter LoadTest2010.mdf.

Man kan så klart även skapa nya instanser per projekt (med SqlLocalDB.exe kommandot, vilket man även använder för att starta och stoppa instanser mm), eller använda den Projects instans som Visual Studio redan skapat, och skapa LoadTest databasen i denna. Gör man detta, kan man även använda den inbyggda SQL Server Explorer för att komma åt databasen, eller SQL Object Explorer för att lägga till nya databaser (som att skapa LoadTest2010 databasen):

VS2013 SQL Object Explorer

VS2013 SQL Object Explorer

Bilden ovan är en screenshot från VS2013 där jag öppnat SQL Object Explorer för Projects instansen, och skapat LoadTest2010 databasen i denna istället, genom att öppna sql filen (samma som användes i exemplet ovan med sqlcmd från kommandotolken istället).

Det sista man brukar behöva göra är att begränsa mängden internminne som SQL Server instansen får använda på maskinen. Precis som tidigare är standard inställningen att använda 2TB (dvs allt som finns) och detta kan göra att Visual Studio får slåss med SQL Servern om att använda minnet på maskinen under lasttester med många VU. Jag brukar dra ner mängden minne för SQL Server instansen till 512MB eller 1GB, så att Visual Studio i alla fall har minst 2GB ledigt minne för de virtuella användarna. Detta behöver göras med ett sql kommando, och kan köras med sqlcmd från kommandotolken, eller så kan vi göra detta direkt i VS2013 genom en Query från SQL Object Explorer:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'max server memory', 512;
GO
RECONFIGURE;
GO

Var noga med att köra detta i rätt LocalDB instans 😉

För att sedan konfigurera Visual Studio Loadtest att använda denna databas vid lokala tester anger vi bara en Connection string till våran LocalDB instans där vi skapade LoadTest2010 databasen:

VS2013 Manage Test Controller

VS2013 Manage Test Controller

Enkelt och smidigt, vi slipper hålla på bråka med rättigheter och inställningar i SQL Server, vi behöver inte ens vara lokal admin på maskinen, och LocalDB instansen startas automatiskt när vi startar ett test eller analyserar en körning, och stoppas även per automatik när den inte används längre.

Load Test Service in the Cloud

En annan nyhet i Visual Studio 2013 avseende prestandatester är att det nu kommer bli ännu enklare att köra sina tester från molnet, dvs med agenter och controllers baserade hos Microsoft. Tidigare kunde man relativt enkelt skapa Azure instanser som är antingen Controllers eller Agents och sedan ansluta till dessa från VS2012, men nu finns en ny moln tjänst som tillhandahålls av Team Foundation Service online. Den är än så länge helt konstnadsfri, men begränsad till 1 Agent och 1 Core, samt 15000 VU minuter per månad. Detta är dock under beta perioden, efter det kommer man troligen få ett antal agenter och minuter gratis i sitt MSDN abonnemang, och sedan kunna köpa till sig mer precis som i Azure.

Det som krävs för att komma igång idag är ett konto, och sedan är det mycket enkelt att koppla upp sig till sin TFS Cloud Load Test miljö (en per användarkonto). Läs mer om detta här.

Fler förinstallerade plugins

Med 2013 kommer även lite nya funktioner, främst i form av plugins.

VS2013 Web Test Plug-ins

VS2013 Web Test Plug-ins

Ovan en bild av de plugins som följer med, samt våra plugins från Lights In Line. De uppifrån fram till och med Generate SAML Token är de som följer med, samtliga genererar alltså automatiskt data. Datum generator kan utgå från ett fast datum, eller tiden just nu, och även lägga till valfri tid i dagar eller timmar och sekunder.

VS2013 Web Test Request Plug-in

VS2013 Web Test Request Plug-in

Bilden ovan visar de Request plugins som följer med efter installationen. Dessa kan användas för att ändra på eller sätta parametrar för ett specifikt anrop i skriptet. Tex finns här stöd för nästlade parameter konstruktioner (se beskrivningen ovan). Samma datum plugin som för webtests finns även här för specifika anrop.

Load test plugins finns det tyvärr inga out of the box än så länge, dock fungerar fortfarande våra plugins från LIL precis som innan, även om du kör dina loadtest projekt med .NET 4.5 (då vår plugins DLL är byggd med VS2010 och .NET 4.0).

Våra plugins hittar du som tidigare på prestandatest.se. Happy Testing!

APM Verktyg och lättviktsprofilering med MEAM APM Insight

Bild Prestandaforum Stockholm 2013-10-09

Bild Prestandaforum Stockholm 2013-10-09

Igår höll vi en kortare föreläsning på Prestandaforum i Stockholm, denna gång sponsrat av Prolore och i deras lokaler. Föreläsningen gav lite insikter i Application Performance Monitoring (APM), varför det är ett hett ämne idag, en snabb översikt över fördelar och varför det behövs, några av de verktyg som finns på marknaden idag samt en presentation och demo av verktyget Manage Engine Applications Manager (MEAM) och dess lättviktsprofileringsmöjligheter i produktion och prestandatest, APM Insight.

Presentationsmaterialet hittar ni här: APM och MEAM APM Insight

Prestandatest kan spara enorma summor pengar

Många tänker nog att syftet med prestandatester är som mycket annat inom test, validera krav och säkerställa att applikationen presterar som det kommer förväntas av den. Och visst är det så, prestandatester ger en trygghet att veta och inhämta kunskap om hur en applikation kommer att bete sig under belastning av många besökare eller användare, samt att infrastrukturens kapacitet räcker till.

Men lika mycket nytta gör prestandatest när den används för optimering och kapacitetsplanering. Relativt nyligen gjorde en av våra största kunder en större resa där infrastrukturen byttes ut avseende processorarkitektur, man gick från SPARC baserad teknologi till Intel x86 på samtliga servrar. I samband med detta gjordes såklart noggranna prestandatester för att validera att den nya infrastrukturen inte presterade sämre än den förra, och förhoppningen var dessutom att mäta upp en förbättring avseende prestanda.

Resultaten av de initiala testerna visade på en potential att ytterligare förbättra prestandan  genom optimering av konfigurationen för applikationsservern, avseende antal processer, trådar och minneskonfiguration per virtuell maskin. Lights In Line rekommenderade därför fler tester efter att det var bekräftat att den nya infrastrukturen höll måttet, med syfte att hitta den optimala konfigurationen. Efter ytterligare 1 veckas intensiva tester av alternativa konfigurationer, hittade vi en som gav maximal prestanda och utnyttjade kapaciteten optimalt, med resultatet att antalet fysiska maskiner i klustret kunde halveras med bibehållen kapacitet och prestanda av applikationen.

Förutom den skära kostnadsbesparingen av antalet fysiska servrar i datahallen, kunde vi påvisa en enorm besparing avseende licenser, förvaltning och underhållskostnader, på närmare 2 miljoner kronor för denna kund, per år. Inte nog med det, men på grund av det mindre antal servrar blev bonus effekten att tiden det tar att göra en ny deploy av koden även minskades vid varje release.

Performance Engineering är inte ett nytt ord för prestandatester. Det är konsten att optimera och förvalta applikationer och tjänsters tillgänglighet, prestanda och kapacitetsutnyttjande, men även att effektivisera processerna runtomkring, i hela lifscykeln.

Mäta prestanda i Oracle under belastning

Bra enkla billiga verktyg är något som är väldigt trevligt att ha i verktygslådan. Här kommer ett som jag fick upp ögonen för här om dagen, som ger väldigt trevliga grafer, sammanfattar de viktigaste mätvärdena och har även en hel del stöd för att optimera och undersöka vart Oracle spenderar tid och resurser samt även för att profilera och utvärdera olika exekveringsplaner mm.

Verktyget är helt gratis och heter MyOra. Version 3.5 har nyligen släppts och här nedan kan ni se en screenshot just över de key performance metrics som är intressanta att se under ett prestandatest;

Screenshot från MyOra 3.5

Fördelen med MyOra är att det är en stand-alone Java applikation, som inte behöver installeras utan kan köras rakt av. Den kräver heller inte att Oracle Native Client är installerad utan den behöver endast Oracles JDBC jar fil i samma mapp som programmet. Verktyget kopplar sedan upp sig som en vanlig användare mot databasen (användaren behöver dock rättigheter att få läsa alla V$ Stats vyer i Oracle instansen).

Mer info och nedladdning hittar ni här: http://www.myorasql.com/

Java Heap GC analys under prestandatester

Garbage Collections i Java heapen under belastning är en av de första områden man kan anpassa och justera för att få bättre prestanda. Denna artikel ger lite tips för hur man kan göra.

Det första man behöver är ett verktyg för att se och analysera heapens utnyttjande under ett prestandatest. Det finns flera sätt att göra detta, både i realtid via tex JConsole som ingår i JDK’n, via olika applikationsservrars verktyg eller genom att slå på GC loggning för JVM’n. Den senare är att föredra, då det är relativt generellt oberoende på vilken leverantör av JVM man använder, Oracle, IBM, m.fl. I princip alla VM kan logga GC statistik till en log fil. Denna log kan sedan analyseras manuellt för den inbitne GC specialisten, eller så använder man ett vertyg som GC Viewer för att analysera denna. I denna artikel tipsar vi just om detta verktyg och visar lite vad man får ut av detta.

Till att börja med kan man ladda ner den senaste versionen av GC Viewer (1.32 i skrivande stund) från GitHub. Verktyget är open source och man kan ladda ner färdiga binärer eller källkoden om man känner för att göra lite kompletteringar i verktyget. Hemsidan på GitHub hittar ni här, och binärer laddas ner från Wikin på samma sida:

GC Viewer på GitHub

Beroende på vilken leverantör av VM man har slår man på loggningen på olika sätt. Listan nedan visar hur man gör det för de VM och versioner som GC Viewer 1.32 stödjer;

- Sun / Oracle JDK 1.7 with option -Xloggc:<file> [-XX:+PrintGCDetails] [-XX:+PrintGCDateStamps]
- Sun / Oracle JDK 1.6 with option -Xloggc:<file> [-XX:+PrintGCDetails] [-XX:+PrintGCDateStamps]
- Sun JDK 1.4/1.5 with the option -Xloggc:<file> [-XX:+PrintGCDetails]
- Sun JDK 1.2.2/1.3.1/1.4 with the option -verbose:gc
- IBM JDK 1.3.1/1.3.0/1.2.2 with the option -verbose:gc
- IBM iSeries Classic JVM 1.4.2 with option -verbose:gc
- HP-UX JDK 1.2/1.3/1.4.x with the option -Xverbosegc
- BEA JRockit 1.4.2/1.5 with the option -verbose:memory

Best results are achieved with: -Xloggc:<file> -XX:+PrintGCDetails -XX:+PrintGCDateStamps

Verktyget visar sedan en rad olika statistiska värden för testet:

Ovan en bild av summerings fliken samt en graf över totala heap storleken (i detta fall 2G), tenured/oldgen heapen (går i lila) samt young heapen (gul). Tumregeln är att Young heapen ska vara cirka 1/3 – 1/4 i storlek jämnfört med Old/Tenured heapen. Det går då snabbt att göra en normal GC (flytta minne från young till old) och det kommer ta längre tid innan old gen måste rensas (Full GC).

De plottade linjerna i grafen är storleken på använt minne i respektive heap. Den gråa i den gula heapen (young gen) ser vi ökar och minskar väldigt ofta, detta är de normala GC som görs när young heapen blir full, och data som fortfarande används flyttas då till oldgen/tenured heapen istället för att raderas. Oldgen/tenured heapen är den som går i lila, och det är här som vi ser om man har ett minnesläckage eller inte, om denna ökar konstant efter varje rensning, vilket oftast inte görs förräns vid en Full GC.

Genom att studera young gen GC frekvensen i grafen över tid, ser vi även väldigt tydligt när vårt prestandatest börjar och slutar, vilket är cirka 20 minuter efter start av VM:et (början på log filen) samt sedan 8 timmar framåt. Grafens tidsaxel kan förstoras i valfri antal procent, i fallet ovan använder vi 20% för att få plats med de första 9 timmarna, så vi ser tiden för hela prestandatestet.

Summeringsfliken ger en sammanfattning för de viktigaste mätvärden att titta på. Antal fulla GC pauser tex, vilket pausar alla anrop under en ganska lång tid (dvs användare för längre svarstider). Även normala GC pauser ger användare längre svarstider, men dessa tar normalt sätt mycket kortare i tid än fulla GC.

Genomströmningen visar i procent hur mycket overhead GC arbetet står för. Den ska vara så nära 100% som möjligt, då den minskar ju mer overhead vi har i VM:et. Hög overhead visar på att vi har för lite tillgängligt minne, och VM:et spenderar för mycket tid på att hantera garbage. En tumregel är att denna inte ska vara under 98%.

Fördelningen mellan normala GC och antalet Fulla GC ska även vara så låg som möjligt för att undvika långa pauser som ger längre svarstider. Ovan gör vi 545 GC pauser totalt, varav endast 2 är fulla GC. Verktyget kan även i tidslinjen markera när en Full GC sker. När minnet börjar ta slut, gör VMet väldigt många fulla GC och mjoriteten av tiden börjar läggas på detta, man får då väldigt höga svarstider för användarna. Tiden som spenderas på GC kan man även se separat i verktyget, samt finns en särkild flik för denna;

Det gröna plottade mätvärdet i grafen ovan är tiden det tar att utföra en GC, vare sig den är normal, full eller en parallell CMS (Concurrent Mark Sweep) GC, då vi i detta fall använder den nya CMS Collectorn i Java. Den peaken som ses i grafen på över 2 sekunder är en Full GC. Dessa vill vi alltså minimera i antal under ett belastningstest, och genom att ställa in GC heaparnas storlek optimalt kan vi minska behovet eller anledningarna till att göra fulla GC.

Som sista analys kan man även i mer detalj analysera varje GC som görs och hur lång tid den tar i form av tabeller, samt visar fliken Minne i mer detalj hur mycket som rensas:

Ovan ser vi detalj fliken för de olika GC som utförs, vi ser bland annat att det görs 518 GC i young gen, 13 CMS GC (Concurrent Mark Sweep) samt 2 fulla GC (hela heapen rensas) samt statistik för hur lång tid de tar att utföra. Minnes fliken till höger ger dessutom information om hur mycket som rensas samt storleken före och efter och indikationer på hur mycket heaparna ökar i storlek.

Sammanfattningsvist visar grafen på minnesallokeringen i old/tenured heapen för detta test att den ökar konstant under de 8,5 timme som vi testar. Detta indikerar ett minnesläckage. Det har gjorts 13 parallella GC samt 2 fulla GC under testet, och de parallella verkar inte kunna hålla old/tenured heapen i schack, då den ökar konstant. Prestandatestet vi gjorde var dock för kort i tid (8 timmar) eller hade för låg last för att ett problem skulle hinna uppstå under testet. Inga anrop gick nämligen fel, och svarstiderna under testet visade inte på en ökning. Vi ser dock att i slutet på testet allokerar vi cirka 1G av de 1,5G som finns tillgängliga för oldgen/tenured heapen, och ytterligare en körning på 8 timmar borde i så fall visa om VM:et överlever situationen och börjar göra fler fulla GC för att rensa minnet. Eller så visar det på att fulla GC inte heller klarar att rensa heapen, och då hamnar vi istället i en situation där fler och fler fulla GC görs (vilket ger längre och längre svarstider för användarna), Genomströmningen och därmed GC Overhead ökar markant, samt hamnar vi till slut i ett läge där minnet tar slut, och vi hittar OutOfMemory exceptions i loggarna, och VM:et slutar att svara på anrop för användare (ger fel eller bara timeout) tills det har startats om. Dessa situationer blir rätt kostsamma att hantera i produktionsmiljön och de vill vi hitta tidigt så vi hinner lösa dem, alternativt planerar att hantera dem så snabbt som möjligt i produktion.

Fördelen med att analysera minnet på detta sätt är att vi har log filer som vi kan analysera i efterhand och även spara tillsammans med test resultaten för körningen, så att vi vid behov även kan göra analyser på tidigare körningar för att göra jämnförelser. Man kan med fördel även slå på GC loggningen i produktion då denna kostar väldigt lite resurser (dock lätt några gig disk space). Man kan då även jämnföra GC beteende i produktion med hur det betedde sig under prestandatester.

Analys av GC som ovan hjälper även till att svara på frågor som hur stor heap ska vi ha per VM, vilken fördelning mellan Perm, Young och Old/Tenured, vilken effekt ger parallell GC, eller olika Garbage Collectors på prestanda och svarstider, samt hur många VM ska vi ha per server för att optimalt utnyttja infrastrukturen och minnet.

Det är vid dessa tester viktigt att en virtuell användare i prestandatestet belastar systemet på rätt sätt (produktionslikt) avseende minnesutnyttjade. Det innebär bland annat att antalet sessioner, inloggningar, användande av funktioner och sessionens livstid under testet för en användare behöver stämma överens med riktiga användares beteenden så väl som möjligt.

Har ni frågor eller synpunkter eller behöver hjälp att komma igång med Java Heap GC analyser så kontakta oss gärna :)

Siemens Healthcare säkrar prestanda i Melior journalsystem

 

Fredrik Lennartsson, Test Manager på Siemens

Fredrik Lennartsson, Test Manager på Siemens

Fredrik Lennartsson arbetar på Siemens som Test Manager tillsammans med ett testteam på 10 personer som är inriktade på journalsystemet Melior. När systemet skulle säkerställas för ca 9000 samtidiga användare tog Siemens kontakt med Lights In Line som är specialister inom området prestandatester.

Siemens är ett minst sagt imponerande företag som började sin resa för 165 år sedan. Idag erbjuder Siemens världens största miljöportfölj med innovativa och högteknologiska lösningar inom områdena infrastruktur, industri, energi, hälso- och sjukvård. I Sverige har Siemens  cirka 4 700 medarbetare på ett 40-tal orter med huvudkontor i Upplands Väsby. Förra affärsåret var omsättningen ca 18 miljarder kronor.

Hälso- och sjukvård är ett av de områden där Siemens är en av de världsledande aktörerna. I Sverige levereras bland annat flera journalsystem och kundanpassade IT-lösningar för hälso-och sjukvård där bl a journalsystemet Melior och processtödet för förlossning och mödrahälsovård, Obstetrix, ingår. I effektiviseringens spår håller nu landstingen på att gå från lokala sjukhusinstallationer  till system på regional nivå. Detta innebär att system som tidigare skulle klara av upp till 3000 samtidiga användare nu i de regionala lösningarna kräver att de kan klara av upp till 9000 samtidiga användare.

Samtidigt pågår flera olika projekt med nationella lösningar t ex NPÖ (Nationell patientöversikt), som skall matas med information från de lokala/regionala systemen.

”- Och det är här som Lights in Line kommit in i bilden. Med sin långa erfarenhet och metodologi kring strukturerad prestandatest har de tillsammans med Siemens Healthcare implementerat nya arbetsmetoder som sparat både tid och pengar.”

Melior omfattar flertalet funktioner, bl a för klinisk dokumentation och läkemedelshantering.  Siemens behövde säkerställa att systemet kan användas på regional nivå och man satte målet till minst 9000 samtidiga användare. Denna siffra baserades på en av kundernas tänkta användande av systemet. Det blev en installation som var 4 gånger större än som tidigare var normalfallet. Installationen behövde testas och Siemens ville ha en erfaren partner för att genomföra detta. Man rådfrågade bl a Microsoft om lämplig partner och de föreslog Lights In Line eftersom det var ett företag som kunde prestandatester.

”- Tillsammans med Lights In Line testade vi Melior och vi har hittat några potentiella flaskhalsar, berättar Fredrik. Vi började med att göra mätningar i en av kundernas produktionsdatabaser för att se hur många transaktioner som genereras i olika moduler över dygnet. I det initiala testarbetet kokade sedan dessa transaktioner ner till ca 15 användarscenarios som uppskattades täcka in de flesta av de mest frekventa databasförfrågningarna från användarna.”

Projektet leddes av Siemens där Lights In Lines roll varit att stå för teststrategi, testmetodik och expertis. En bit in i projektet fick Siemens också möjlighet till ett aktivt samarbete med Intel som ville utvärdera ett effektivare serveranvändande samt även testa sina nya generationer av servrar. I Intels tekniklabb i Kalifornien kunde sedan Siemens och Lights In Line tillsammans testa systemet i en fullskalig miljö med simuleringen av 9000 samtidiga användare.

”- Lights in Line baserar sin metodik kring prestandatester på tre hörnstenar – stabilitet, samtidighet och skalbarhet – och med detta tankesätt har man under projektets gång säkerställt Meliorsystemet i flera avseenden och verifierat att det idag klarar ett framtida, mer omfattande användande.”

”- Sista pusselbiten i detta säger Fredrik, är att vi tillsammans med landstingen ska få detta att fungera. Ett sådant här stort projekt ställer höga krav på exempelvis nätverk och IT-infrastruktur. Vi ser dock en effektivisering som kommer att förbättra för den svenska sjukvården.”


FOTNOT

Initialt började projektet redan 2009 då Siemens efterfrågade en utredning vilket prestandatestverktyg man skulle välja för att göra storskaliga tester av Melior. Då Siemens utvecklat hela lösningen själva i Microsofts miljö, var Visual Studio en av kandidaterna, och efter en intern Proof of Concept tillsammans med LIL det verkyg som användes för samtliga prestandatester sedan dess.

Rent tekniskt är Melior uppbyggd med blandade tekniker, med en rik client/server lösning som den huvudsakliga applikationen kombinerad med en modern 3 lager lösning och tekniker som WCF och tunna webbgränsnitt. De 15 användningsfallen som i huvudsak användes under prestandatesterna nyttjar alla tre av dessa tekniker och samtliga är utvecklade tillsammans med samma team hos Siemens som även utvecklar applikationen. Därmed kan även dessa komponenter versionshanteras tillsammans med all annan kod i applikationens lifscykel och även testas av utvecklarna att de fungerar med kommande versioner innan vi utför prestandatester. 

Visual Studio 2012 Load Test Licenser och Installation

Nya Visual Studio 2012 har igen en ny licensmodell när det gäller Load Test. De gamla VU Packen och modellen att ta betalt per VU eller hur mycket last du kan generera är nu ett minne blott och helt borta.

VS2010

För 2010 fanns det 2 olika licenser för load test controllern, en obegränsad som ingår i MSDN för Ultimate som är personlig och därmed får användas vart som hellst av den personen och installeras på ett obegränsat antal ställen, samt VU Packs på omgångar av 1000 VU som inte är personliga (som MSDN) men är knytna till ett företag/site och endast får installeras på 1 ställe i taget.

VS2012

För 2012 har man helt tagit bort VU Packs, det enda som finns är obegränsade licenser i MSDN som är personliga. Microsoft har gått ut med detta genom att helt enkelt säga att gränsen är borta, och jag märkte det efter att jag precis nyligen gjorde min första installation av en 2012 Controller, och funktionen att lägga till licensnycklar för VU Packs är helt borta. Du behöver alltså ingen nyckel alls för att installera Controllern eller Agenten, det enda du ska göra är kryssa för att du accepterar licensavtalet där det står att du måste ha Ultimate + MSDN.

Jag har de senaste dagarna fått ett antal frågor om detta, så nu vet ni alla som ska köra prestandatester med VS2012 att det enda du behöver är alltså Visual Studio 2012 Ultimate + MSDN.

Det går även en myt att Microsoft nu ska ta betalt per VU, men det är alltså tvärtom. Man kan inte längre betala per VU, vilket man endast kunde i 2010 :)

Installation

Till att börja med är det bra att veta att VS2012 kräver minst Windows 2008 Server / Windows 7 eller nyare. Installationen av en 2012 Load Test Controller görs precis som innan, skivan heter numera Agents for Visual Studio 2012 och du laddar ner den precis som tidigare med ditt personliga MSDN konto. Skillnaden i 2012 är att du inte längre behöver någon licensnyckel alls.

Användarkontot som du anger att Controllern ska köra med behöver ha rättigheter i SQL Server att skapa och administrera LoadTest2010 databasen. Är man inte riktigt van vid SQL Server 2008 så är det en vanlig fallgrop, bara för man är Administrator på maskinen är man inte det automatiskt i SQL Server längre, du behöver alltså ge dessa rättigheter först till den användaren. Det gäller även Windows i sig så jag rekommenderar att skapa ett specifikt system konto innan du sätter igång för controllern och agenterna, och ge kontot admin rättigheter, vara inloggad med det när du installerar samt alltid köra installationer samt konfigurationsprogrammen med elevated rights (högerklicka och välj kör som administratör) för att slippa problem med automatisk brandväggskonfiguration och när konfigurationsprogrammen försöker ge kontot rätt rättigheter i controllern när du sätter upp en agent på en annan maskin.

Load Test Databasen som skapas när du konfigurerar 2012 Controllern heter dock fortfarande LoadTest2010 så bli inte förvånad när du inte hittar en som heter 2012… därmed verkar databasen även kompatibel med 2010 versionen vilket är en klar fördel denna gång. Jag har än så länge inte uppgraderat en befintlig 2010 test rig med en full databas till 2012, men så fort vi har gjort det uppdaterar jag denna artikel med våra erfarenheter av det.

Lycka till! Och behöver ni hjälp så finns vi här…

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.

Lights in Line håller koll på Bisnodes affärskritiska system

Bisnode_skärm

Ovan en bild på skärmen i Bisnodes operation center som visar status på alla monitorerna, de senaste larmen samt dagens tillgänglighet.

När man nämner företagsnamnet Bisnode så skakar nog de flesta på huvudet. Men när man blir klar över vilka tjänster som de faktiskt levererar är det dess fler som nickar igenkännande. I tjänstemenyn hittar man välbekanta produkter som till exempel kreditupplysningar och finansiell information från Soliditet och Dun & Bradstreet, adresser från PAR, CRM-system, pressreleaser, direktmarknadsföring, nyhetsbrev och mycket, mycket annat.

Det som en gång startade som Bonniers Affärsinformation har idag 4,3 miljarder i omsättning, 3000 anställda och verksamhet i 17 länder. Idag handlar Bisnodes verksamhet om avancerad informationshantering, vidareförädling och leverans i realtid. Företagets egen framtidsutsikt är att bli den ledande leverantören av affärsinformation i Europa och erbjuda de bästa produkterna och lösningarna. Sammanfattningsvis handlar det om att samla in data, sortera, aggregera och förpacka information som sedan levereras som en paketerad tjänst till kunden.

I en verksamhet som i stort sett enbart handlar om informationshantering är det givet att övervakning av tillgänglighet är A och O och det är här Lights In Line har kommit in i bilden och sedan 2006 har man jobbat tillsammans.

Bisnode_Sven_Täveby

Bisnodes Sven Täveby

Sven Täveby arbetar på Bisnodes interna IT-avdelning i Sundbyberg och ansvarar för övervakningen av de affärskritiska systemen.

”- Vi har jobbat ihop med Lights In Line ett bra tag nu och mitt intryck är att det är ett mycket högkompetent gäng som är både rappa och smidiga att jobba med, säger Sven. Att övervaka IT kan man givetvis göra internt men det är en helt annan sak när en tredje part gör det. Det ger en helt annan seriositet och en helt annan trygghet. Jag känner hela tiden att jag har full koll på vad som händer.”

Lights In Lines tjänst består i att kör ett antal script som simulerar vanliga användare och som loggar på tjänsterna var 5:e minut. Sedan rapporteras status kring tillgängligheten till den som just för stunden har ansvar för beredskapen hos Bisnode, som även med hjälp av Lights In Lines mobil-app kan ha koll på att systemen är uppe. Går något fel så skickas omedelbart ett SMS från Lights In Line till Bisnode.

”Övervakningen har också resulterat i att Bisnode kunnat se att deras Internet-leverantörer plötsligt ändrat i sina routers, något som får betraktas som en överaskande bonusinformation.”

Bisnode LILMA Mobil App

Bisnode LILMA Mobil App

Ett annat spännande teknikområde är övervakning av IP-telefoni, något som Lights In Line skall börja titta på tillsammans med Bisnode i en nära framtid. Eftersom IP-telefoni i princip kräver samma typ av övervakning och prestandaoptimering som Lights In Line redan idag arbetar med är det här ett område där det är sannolikt att man kan bidra med kompetens och expertis.

”Fler och fler i Bisnode-koncernen efterfrågar också Lights In Lines tjänster i takt med att man succesivt siktar på att i höst gå från 18/7 beredskap till 24/7. Fler övervaknings-script är på gång att installeras och Lights in Line tar en roll som ”domare” över tekniken. Statistik över de olika systemens tillgänglighet har nu också börja dyka upp på interna möten hos koncernens olika tjänsteansvariga vilket naturligtvis är helt rätt. Säljer man tjänster på nätet är ingenting viktigare än att allt fungerar utan dröjsmål. Annars är kunden borta på tre röda sekunder…”


Fotnot

Bisnode är en av våra första större implementationer av övervakningslösningar. De gjorde från början en mycket seriös upphandling, där flera leverantörer fick visa upp sina lösningsförslag samt genomfördes även en PoC (Proof of Concept) med två utvalda leverantörer. Vi valde att basera lösningen på ett verktyg från ManageEngine, Applications Manager, och byggde ut denna med en egen implementation av en script motor för testautomatisering som vi kallar LILSE. Tack vare våra erfarenheter att tillverka skript som klarar förändringar på sajten utan att felaktigt larma, samt vår styrka att kunna anpassa och förädla produkter till kundens behov, fick vi förtroendet att implementera lösningen.

Idag har vi även anpassat lösningen till att kunna mäta tillgänglighet under flera parallella tidsperioder då Bisnodes kunder har olika SLA på en och samma tjänst. Vi har även lagt mycket tid på att minimera falska larm som beror på tillfälliga störningar, samt processer och systemstöd för att snabbt kunna avgöra vad felen beror på. Vi trendanalyserar även feltyperna månad för månad för att kunna hjälpa vår kund att kontinuerligt förbättra sin tillgänglighet.