Rätt fokus vid prestandatester och övervakning av IT-system.

 

Vid övervakning och prestandatester av IT-system finns en tendens att först välja verktyg och sedan inleds processerna hur det skall användas i verksamheten.

Börja istället och ställ  frågorna:

1. Vilken ambitionsnivå skall vi ha på prestandatester, skall det göras vid varje release av ny kod eller infrastruktur, eller kanske bara när det anses nödvändigt?

2. Omfattningen på prestandatester, skall vi testa många användningsfall/scenarier eller koncentrera oss på få användningsfall?

3. Vilka kriterier skall vi ha för att prestandatestets resultat anses godkänt eller ej, eller inga?

4. Till vilken eller vilka skall resultatet av prestandatesterna presenteras, är det enbart till tekniker eller till verksamheten eller kanske till båda?

5. Vilken ambitionsnivå skall vi ha på övervakningsverktygen, skall vi mäta hur servrarna mår infrastrukturellt, skall vi mäta hur många som använder systemen och dess olika funktioner, skall vi mäta svarstider utifrån användarens perspektiv, eller allt?

6. Hur skall presentationen vara och till vem, skall vi skicka rapporter eller skall alla kunna gå in och ta ut rapporter, skall en ansvarig grupp samlas och någon som föredrar resultatet?

7. Vilken upplösningsnivå och nåbarhet skall det vara på resultaten i övervakningen?

8. Skall övervakningen baseras på uppmätta siffror i produktion (passiv övervakning) eller skall det vara aktiv övervakning (en robot simulerar en användare och genomför mätning med jämna mellanrum), eller skall vi ha båda?

9. Avser vi att ha långsiktlighet i processerna prestandatest och övervakning eller är detta något som vi avser att göra under en kort tid?

10. Vilka skall få larm om tröskelvärden överskrids vid övervakningen och hur skall larmen eskaleras.

11. Vill vi ha in resultatet av prestandatesterna och övervakningen i något SLA avtal (service level agreement) eller det är inte intressant?

12. Hur viktigt är det att IT-systemen fungerar och har godtagbara svarstider?

Ovan nämnda frågor renderar i att man bestämmer ambitionsnivån och även hur prestandamätning och övervakning blir en del i organisationen.

Observera att det finns ingenting som är rätt eller fel i ambitionsnivån på prestandatesterna/övervakningen, det viktiga är att du är medveten att ambitionsnivå/kostnad/bättre proaktivitet hänger ihop

Efter detta välj verktyg och välj också om du behöver extern part att hjälpa till eller om du klarar det själv.

Vi på Lights In Line har under många är byggt upp en erfarenhet inom områdena prestandatest, övervakning och framför allt hur kombinationen av dessa processers resultat kan bidraga till bättre koll på dina IT-system.

Kontakta oss så kan vi prata om det som vi brinner av på Lights In Line.

Bo Svensson

070-5940948

 

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…

Öresundskraft.se till molnet och Lights In Line prestandatester

Öresundskraft är ett av Sveriges större energibolag. Kärnverksamhet är försäljning och distribution av energi (el, fjärrvärme, naturgas och fjärrkyla) samt försäljning av bredband och fordonsgas. Försäljning och distribution av el drivs i två separata bolag enligt reglerna i ellagen.

 

I samband med ny design av hemsidan så beslöt man att byta plattform och flyttade till Microsofts molnmiljö, Windows Azure.

Efter kontakt med Lights In Line togs beslut om att kvalitetssäkra prestandan och tillgängligheten av webbplatsen i den nya miljön.

Lights In Line satte genast igång med prestandatest och applikatorisk övervakning, dvs. se hur användaren upplever svarstiderna, på webbplatsen innan flytten. Resultatet av dessa tester jämfördes med prestandatesterna på den nya webbplatsen i molnet och fick godkänt.

Charlotte Dunder Forslin, produktansvarig Extern webb på Öresundskraft:
”Det kändes tryggt att ta hjälp av Lights In Line AB för att kvalitetssäkra prestanda och tillgänglighet för den nya hemsidan i samband med byte av både CMS och plattform.  Dessutom kunde vi med Lights In Line på ett enkelt sätt utforska och mäta prestandaförändring vid upp- respektive nedskalning av kapaciteten.

Den applikatoriska övervakningen före och efter flytten är användbar i proaktivt syfte.”


Är det dyrt att prestandatesta webbplatser eller applikationer ?

Prestandatester kan jämföras som försäkringspremier. Om din villas tak  inte håller för stormen och den inte är försäkrad så torde försäkringspremien vara billig i jämförelse med skadorna på villan. Om din webbplats inte håller för en anstormning av besökare så är kostnaden för prestandatest INNAN anstormningen troligtvis billig …..

Att prestandatesta alla webbplatser i samma omfång och samma ambitioner gör att det kan bli både dyrt och tragiskt. Om holländarna inte genomför omfångsrika provtryckningar på sina vallar så kan det bli tragiskt för invånarna. Därför är provtryckningarna av vallarna i Holland billiga även om dom kostar miljoner per år. Om regalskeppet Wasa hade testats (alltså genomförd stabilitetstest och analys hade det troligen medfört  mera barlast i kölsvinet och därmed mindre krängning) så hade det varit tragiskt för Polen.

Därför så sätter vi på Lights In Line oss alltid in i kundens situation och ambition innan vi kommer med ett förslag på prestandatest. Vi resonerar med kunden, hur mycket värt är det att webbplatsen/applikationen håller för anstormningen och lämnar därför rätt pris i förhållande till vad kunden vill uppnå. Det händer ofta att kunden vill utföra omfångsrika prestandatester och vi säger ”börja i liten skala först”, utvärdera därefter och återkom.

Genom att vi dessutom levererar prestandatesten som en tjänst vet kunden alltid slutpriset, lika självklart som att köpa ett tak till sitt hus till fast pris.

Hemligheten med att ha fast pris som dessutom är billigt är väldigt enkelt. Många av oss på Lights In Line  har hållit på med prestandatester i över 20 år och vet vad som kan vara fördyrande, exempelvis :

-Hyr in en konsult låt oss säga i 6 månader för prestandatest heltid, i de flesta fall är över 50  procent väntan, vem betalar 🙁

-Ha stora ambitioner och man testar så mycket att verksamheten inte kan ta åt sig resultatet, om man kommer i mål 🙁

Samma prestandatestare hos oss kan från vårt kontor vara prestandatestare åt flera kunder samtidigt och genom att alltid ha minst 2 medarbetare på varje kund har vi redundans, våra medarbetare kan bli sjuka och dom får ta semester 🙂

Prestandatest av din webbplats eller applikation och att ha koll på tillgängligheten är vår passion, kontakta Bosse på 070-5940948 eller Christian på 070-2209828.