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

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 🙂

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…

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