Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Optimering av prestanda och utnyttjande av
flertrådsteknik
av
Daniel Gustafsson, Christoffer Öberg
LIU-IDA/LITH-EX-G--09/016--SE
2009-12-17
Linköpings universitet
Institutionen för datavetenskap
Examensarbete
Optimering av prestanda och utnyttjande av
flertrådsteknik
av
Daniel Gustafsson, Christoffer Öberg
LIU-IDA/LITH-EX-G--09/016--SE
2009-12-17
Handledare: Fredrik Anderberg
Examinator: Patrick Lambrix
Presentationsdatum
2009-12-17
Publiceringsdatum (elektronisk version)
2010-01-24
Institution och avdelning Institutionen för datavetenskap Department of Computer and Information Science
URL för elektronisk version
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-53468
Publikationens titel
Optimering av prestanda och utnyttjande av flertrådsteknik Optimization of performance and utilization of multithreading
Författare
Daniel Gustafsson, Christoffer Öberg
Sammanfattning
Detta examensarbete gick ut på att hjälpa företaget Medius AB med att optimera utvalda delar i ett befintligt system för att korta ner exekveringstiden genom att implementera flertrådsteknik. Tanken var att strukturera om i koden så att flera beräkningar kunde göras samtidigt. Arbetet innefattade tre stycken optimeringar. Den ena bestod av att göra om en stor ”for-loop” till att köra varje loops arbete i en egen tråd. Den andra optimeringen var också att bryta ut en ”for-loop” till att köra allt arbete i olika trådar. Den tredje och sista innebar att bygga om en lagrad procedur i databasen, så att olika delar av den kunde köras i varsin tråd för att skapa data parallellt. För att implementera optimeringarna så användes VB .NET och dess stöd för bl.a. trådtekniker och anslutningspool. Resultatet av dessa optimeringar innebar att en modul kunde
effektiviseras så att körtiden blev 12 % snabbare, och en annan modul kunde effektivisera körtiden med 25 %. D.v.s. syftet och kraven för examensarbetet blev uppfyllda genom att systemet nu utnyttjar servrarnas resurser på ett bättre sätt.
Nyckelord
Flertrådsteknik, Optimering, Visual Basic, .NET
Språk
x Svenska
Annat (ange nedan)
Antal sidor 39 Typ av publikation Licentiatavhandling x Examensarbete C-uppsats D-uppsats Rapport
Annat (ange nedan)
ISBN (licentiatavhandling)
ISRN LIU-IDA/LITH-EX-G--09/016--SE Serietitel (licentiatavhandling)
Abstract
The purpose of this thesis was to help the company Medius AB with optimiza-tion of selected parts in an existing system to minimize the execuoptimiza-tion time by implementing multithreading. The idea was to manipulate the code so that calculations could be executed at the same time.
The main work in this thesis consisted of three optimizations. The rst one was to reconstruct a big for-loop so it would execute every loop's work in an own thread. The second optimization also was a reconstruct of a for-loop so it could execute the work in dierent threads. The third and last optimization consisted of reconstructing a stored procedure on the database, so dierent parts of it each could be executed in an own thread to create data at the same time. To implement the optimizations Visual Basic .NET and its support for multithreading and connection-pools was used.
The result of the optimizations meant that one of the modules could be executed more e ciently and it was 12 % faster. The other modules execution time was more e cient by 25 % faster. The meanings and requirements for this thesis are ful lled by now letting the system make use of its resources in a better way.
Sammanfattning
Detta examensarbete gick ut på att hjälpa företaget Medius AB med att op-timera utvalda delar i ett be ntligt system för att korta ner exekveringstiden genom att implementera ertrådsteknik. Tanken var att strukturera om i koden så att era beräkningar kunde göras samtidigt. Arbetet innefattade tre stycken optimeringar. Den ena bestod av att göra om en stor for-loop till att köra varje loops arbete i en egen tråd. Den andra optimeringen var också att bryta ut en for-loop till att köra allt arbete i olika trådar. Den tredje och sista innebar att bygga om en lagrad procedur i databasen, så att olika delar av den kunde köras i varsin tråd för att skapa data parallellt. För att implementera optimeringarna så användes VB .NET och dess stöd för bl.a. trådtekniker och anslutningspool. Resultatet av dessa optimeringar innebar att en modul kunde eektiviseras så att körtiden blev 12 % snabbare, och en annan modul kunde eektivisera kör-tiden med 25 %. D.v.s. syftet och kraven för examensarbetet blev uppfyllda genom att systemet nu utnyttjar servrarnas resurser på ett bättre sätt.
Förord
Vi vill börja med att tacka Medius AB och vår handledare Fredrik Anderberg för att de gett oss fullt förtroende under examensarbetet och som stöttat oss när det behövts. Även ett stort tack till övriga medarbetare på Medius som kommit med idéer och hypoteser runt vårt arbete.
Tack till vår examinator Patrick Lambrix för stöd och hjälp med rapporten. Vi vill även tacka Pontus Ek och Rickard Lindner för hjälpen med latex. Till sist vill vi tacka Hanna Eriksson och Lina Gustafsson för att ha korrekturläst rapporten.
Figurer
2.1 Skapa tråd i VB .NET . . . 4
2.2 Skapa trådpool i VB .NET . . . 5
2.3 Skapa anslutningspool i VB .NET . . . 6
2.4 Testprogram . . . 8
2.5 Data vid testkörning . . . 8
3.1 Modulstruktur . . . 16 3.2 Modulstruktur . . . 20 3.3 Original modulstruktur . . . 26 3.4 Optimerad modulstruktur . . . 26 5.1 Resultat modul 1 . . . 32 5.2 Resultat modul 2 . . . 32 5.3 Aktivitetshanteraren original . . . 33 5.4 Aktivitetshanteraren optimerad . . . 33
Innehåll
1 Inledning 1
1.1 Bakgrund . . . 1
1.2 Syfte och mål . . . 1
1.3 Frågeställning . . . 1
1.4 Metod och källa . . . 2
1.5 Avgränsning . . . 2
2 Förstudie och testprogram 3 2.1 Trådtekniker . . . 3 2.2 Process . . . 3 2.3 Tråd . . . 4 2.4 Trådpool . . . 5 2.5 Anslutningspool . . . 6 2.6 Synkronisering . . . 6 2.7 Testprogram . . . 7
2.8 Parameter överföring med byRef och byVal . . . 9
2.9 Multipla attribut till trådar . . . 9
2.10 Delat minne . . . 9
3 Optimering av prestanda 11 3.1 Inledning . . . 11
3.3 Optimering 1 . . . 13 3.3.1 Bakgrund . . . 13 3.3.2 Kravspeci kation . . . 13 3.3.3 Analys . . . 13 3.3.4 Designspeci kation Optimering 1 . . . 14 3.3.5 Struktur . . . 15 3.3.6 Lärdom av implementering . . . 16 3.3.7 Testscenario . . . 17 3.4 Optimering 2 . . . 18 3.4.1 Bakgrund . . . 18 3.4.2 Kravspeci kation . . . 18 3.4.3 Analys . . . 18 3.4.4 Designspeci kation Optimering 2 . . . 19 3.4.5 Struktur . . . 20 3.4.6 Lärdom av implementering . . . 20 3.4.7 Testscenario . . . 22 3.5 Optimering 3 . . . 23 3.5.1 Bakgrund . . . 23 3.5.2 Kravspeci kation . . . 23 3.5.3 Analys . . . 23 3.5.4 Designspeci kation Optimering 3 . . . 24 3.5.5 Struktur . . . 25 3.5.6 Lärdom av implementering . . . 26 3.5.7 Testscenario . . . 28 4 Trådhantering i framtiden 29 4.1 Visual Studio 2010 Beta 2 . . . 29
4.1.1 CPU Utilization / Concurrency Analysis . . . 29
4.1.2 Thread Blocking Analysis . . . 30
5 Resultat 31 6 Slutsats och diskussion 34
6.1 Slutsats . . . 34
6.1.1 Fördelaktiga moduler . . . 34
6.1.2 Eektivitet . . . 34
6.2 Diskussion . . . 35
6.2.1 Omstrukturering av mjukvara i efterhand . . . 35
6.2.2 Väl de nierad designspeci kation . . . 35
6.2.3 Att tänka på vid implementering och vilka fel som kan uppstå . . . 35 7 Framtida arbete 37 Litteraturförteckning 38
Kapitel 1
Inledning
1.1 Bakgrund
Medius är ett IT-företag som i huvudsak arbetar med ekonomisystem och work- ow. Företaget har ett system som är till för att artister, producenter, musiker och skivbolag skall få betalt för deras musik som spelas på radio. Systemet består av ett webbgränssnitt och bakomliggande program som gör beräkningar och hanterar data. En databas används i systemet för att lagra information. Den uppgift som Medius vill ha hjälp med är att optimera prestandan på ut-valda moduler i systemet genom att implementera ertrådsteknik, detta för att utnyttja alla kärnorna i servrarnas processorer. Något som även ska undersökas är om det går applicera ertrådsteknik på lagrade procedurer i databasen för att kunna optimera dessa i databasen.
1.2 Syfte och mål
Syftet med examensarbetet är att optimera utvalda delar ur det be ntliga sys-tem som idag nns driftsatt. Målet med optimeringarna är att modulerna skall utnyttja systemets resurser på ett eektivare sätt. Förhoppningarna med exam-ensarbetet är att optimeringarna skall komma att driftsättas och att dokumen-tationen skall ligga till grund för en vidare optimering av hela systemet.
1.3 Frågeställning
Frågeställningar som skall besvaras: 1. Hur implementeras trådar i .NET?
2. Vad bör tänkas på vid implementering av trådar? 3. Vilka problem kan förekomma vid implementering? 4. Hur ser framtiden ut för trådteknik?
1.4 Metod och källa
Genom att studera litteratur som rör området ska kunskaper införskaas och förståelse inom projektets område för att kunna förstå systemet som skall opti-meras och vilka olika typer av optimeringstekniker som behövs kännas till. Det ska även studeras hur dessa tekniker implementeras i de programmeringsspråk som kommer att användas. Internet är en bra källa för att hitta information om och förståelse för de programmeringsspråk som det behövs information om, men för att få en bra helhetsbild över de teoretiska delarna kommer även litteratur att användas som källor.
För att lösa uppgiften på ett smidigt sätt kommer en kravspeci kation och en designspeci kation att användas för varje optimering.
I rapporten kommer det att tas upp olika lösningsmetoder och olika beskrivningar, samt varför dessa val görs. Problem som uppkommer kommer också att gås igenom och lösningarna som hittas för dem likaså.
1.5 Avgränsning
Uppgiften Medius vill ha hjälp med är att optimera ett driftsatt system. Efter-som systemet är väldigt stort och komplext så har en avgränsning fått sättas upp. Avgränsningen innebär att i samråd med Medius har vissa delar valts ut för att optimeras. Det är två olika moduler som valts ut och vissa utvalda delar ur dessa moduler kommer att optimeras.
Kapitel 2
Förstudie och testprogram
Förstudien började med att relevant litteratur samlades in och studerades, för att få bredare kunskaper inom ertrådsteknik och implementering av detta i Visual Basic .NET (VB .NET) och C# .NET. Dessa kunskaper utgjorde sedan grunden för konstruktionen av testprogrammen som sedan användes för att få en uppfattning om hur olika implementeringar av ertrådsteknik presterar. Dessa kunskaper som inhämtats kunde sedan användas till optimeringen av systemet.
2.1 Trådtekniker
När trådhantering ska implementeras i .NET, används någon utav följande två metoder. Den första metoden kallas för trådning (threading), den andra kallas för trådpool (thread pool). För att trådhantering skall fungera korrekt måste data även synkroniseras så att krockar inte sker. Nedan beskrivs dessa begrepp och vad skillnaden mellan dem är.
2.2 Process
En process är ett program som är under exekvering, samma program kan ex-ekveras era gånger. En process har ett eget minnesutrymme samt stack och den består av en eller era trådar. (Silberschatz, 2005)
Om datorn har en processor med endast en kärna i, så går det att använda sig av något som kallas tidsdelning (time-sharing). Denna princip går ut på att varje process får en liten tid att exekvera. När processen har fått köra sin tid sparas all information om stack, minne osv. och nästa process laddar in sin stack samt data och börjar exekvera. (Silberschatz, 2005)
2.3 Tråd
En process innehåller oftast en tråd men kan även bestå av ett ertal trådar. Om den är ertrådig så kan den utföra era uppgifter samtidigt vilket leder till att en erkärning processor kan använda sig av era kärnor samtidigt för att beräkna data. T.ex. kan ett program ha en tråd som hanterar nätverksdata medan en annan tråd tar hand om att visa text och gra k. (Silberschatz, 2005) Varje tråd har unika ID, processräknare, register och stack men alla trådar inom samma process delar sin kod, data och operativsystemsresurser. Detta tillåter ett program att ha era trådar aktiva inom samma adressrymd i minnet. (Silberschatz, 2005)
Ett exempel på implementering av trådar i VB .NET kan ses på bild 2.1.
Figur 2.1: Skapa tråd i VB .NET
Att allokera minne och resurser för att skapa processer är väldigt kostsamt för systemet men eftersom trådar inom samma process har delade resurser är det mer ekonomiskt att skapa och byta innehåll i trådar. Det är även mer tidskrä-vande att hantera processer än trådar. Det nns två olika nivåer av trådar, användarnivå (user-level) och kärnnivå (kernel-level). Användarnivå trådar har stöd ovan för kärnan men kan manipuleras utan någon påverkan av kärnan, medan kärntrådar skapas och hanteras direkt av operativsystemet. (Silberschatz, 2005)
2.4 Trådpool
Ett problem med trådar är att om alla förfrågningar om att få en tråd att exekvera i sker samtidigt till servern, så kommer systemet inte ha någon be-gränsning för hur många trådar som får vara aktiva samtidigt. Oändligt många trådar som körs samtidigt kan komma att överbelasta systemets resurser såsom CPU och minne. (Silberschatz, 2005)
En trådpool kan användas för att lösa problemet. Trådpoolen fungerar genom att den först placerar alla skapade trådar i en pool. I poolen ligger de ska-pade trådarna och väntar på att bli tilldelade arbete. När servern sedan får en förfrågan (request) väcker den en tråd från poolen och skickar den till en tråd som kör förfrågan. När tråden är klar så kollar servern om det nns några era förfrågningar i kön som kan tilldelas en tråd. Om de inte nns några för-frågningar så lägger sig trådarna och vilar i väntan på en förfrågan i trådpoolen. (Silberschatz, 2005)
Ett exempel på implementering av trådpool i VB .NET kan ses på bild 2.2.
Figur 2.2: Skapa trådpool i VB .NET
Fördelarna med en trådpool är att en förfrågan med en existerande tråd hanteras, vilket gör att det går snabbare än om en tråd skulle behövt skapas när förfrågan kom och sedan tagits bort när själva arbetet är gjort. Poolen begränsar även
antalet trådar som får existera, vilket är väldigt viktigt för system som inte stödjer ett stort antal trådar som körs samtidigt.
2.5 Anslutningspool
Figur 2.3: Skapa anslutningspool i VB .NET
En anslutningspool är en pool som innehåller öppna anslutningar mot databasen. Så fort en anslutning behövs kontrollerar systemet om det nns en ledig anslut-ning i poolen, annars skapas en ny som ges till den som frågat efter den. Efter att anslutningen stängts av användaren, lämnas den tillbaka till poolen fort-farande öppen. Detta gör att era trådar kan använda samma anslutning och att det går snabbare att få och lämna tillbaka anslutningar då de inte öppnas eller stängs utan läggs i en anslutningspool. (Joshi, 2009)
Ett exempel på implementering av anslutningspool i VB .NET kan ses på bild 2.3.
2.6 Synkronisering
Synkronisering är en metod som används för att undgå att processer hamnar i olika tillstånd där variabler kan få fel värden eller att ett objekt anropas sam-tidigt och en kollision uppstår. Med synkronisering kan exekveringsordningen av trådar styras genom att t.ex. vänta in en speci k händelse (event).
När det gäller variabler så används synkronisering för att inte någon annan process skall skriva till en delad variabel som används av en annan process sam-tidigt. Det som kommer att inträa om synkronisering inte används är t.ex. att en process A läser in a=1. Process B läser också in a=1. Process A sätter a=0, direkt efter så ändrar process B a=a+1 då kommer a sättas till 2 då process B använder fel värde i sin beräkning. För att undgå detta synkroniseras processer-na genom att använda sig av någon synkroniseringsmetod som låser variablerprocesser-na
i en process är ett kodblock som enbart får exekveras av en tråd åt gången för att den ska producera rätt resultat. (Silberschatz, 2005)
För att ertrådsapplikationer ska fungera korrekt och producera rätt resultat så måste synkronisering användas. Det nns olika synkroniseringsmetoder. De vanligaste är:
1. Semaphore
(a) Med semaphoren så låses ett kodblock när en tråd går in i blocket och låses upp när den är klar. De som vill exekvera samma kodblock samtidigt ställer sig på kö, ett de nierat antal platser anges vid ini-tiering. (Silberschatz, 2005)
2. Interlock
(a) .NET tillhanda håller också internlås(Interlock). Den användas för att låsa en speci k variabeloperation, t.ex. att en variabel ökar eller minskar i värde. (Liberty, 2003)
3. Monitor
(a) Monitors är inom .NET den vanligaste synkroniseringsmetoden. Mon-itors är till för säker användning av objekt, den låser hela objektet och ger ingen annan tråd tillgång till objektet förrän låset är frigjort igen. (Liberty, 2003)
När synkronisering används i större system eller i system med många processer igång samtidigt så kan synkroniseringsproblem uppstå av olika anledningar. Ett problem som kan uppstå är deadlock. Detta problem uppstår när en process A väntar på en annan process B, som i sin tur väntar på process A. När detta tillstånd uppstår så låser sig båda processer i evighet, detta kallas deadlock. (Silberschatz, 2005)
Ett annat problem som kan uppstå är Readers-writers problem. Om data i minnet läses av olika processer och en process ligger och väntar på att få skriva till den så kan den få vänta länge, detta är Readers-writers problem. Star-vation är också ett problem som kan uppstå. Det innebär att en eller era processer ligger och väntar på att få köra men andra processer prioriteras före, då svälter de processer som väntar, därav namnet Starvation. (Silberschatz, 2005)
2.7 Testprogram
För att förstå hur dessa trådtekniker kan implementeras skapades två test-program, ett i C# och ett i VB .NET. Dessa program skapades även för att utvärdera trådteknikernas prestanda med olika förutsättningar som t.ex. olika antal trådar.
Testprogrammet består av tre stycken knappar och ett fält för att ange antalet processer som skall startas, se bild 2.4. De tre knapparna används för att starta processerna otrådat, trådat eller trådat med hjälp av en trådpool.
Figur 2.4: Testprogram
En klass som innehåller data för varje process som ska köras skapades. Denna klass innehåller en funktion som kör en algoritm för att belasta processorn. Klassen innehåller även funktioner som startar belastningsfunktionen i en tråd eller i en trådpool. Testprogrammet kan generera mätdata om hur lång tid det tog för datorn att köra alla dessa processer som skapades. Detta är intressant då hur mycket tid som kan tjänas på att köra med trådar eller med en trådpool kan ses. Vid testkörning så kördes cykler med 5, 10, 20, 40 och 80 processer. Dessa cykler kördes otrådat, trådat och med en trådpool. Vid testkörningen så genererades data som visas i bild 2.5.
Testkörningen gav den information som bekräftade det som efterfrågades, dvs. att det är lönsamt att implementera trådteknik i ett system med er processer som skall köras. Enligt bild 2.5 så ses tydligt att det blir ca. 50 % kortare körtid. Skillnaden mellan tråd och trådpool är inte så stor.
2.8 Parameter överföring med byRef och byVal
I VB .Net så kan två sätt användas för att skicka parametrar till en process. Det första är byVal (by value) som innebär att ett värde skickas in till processen, detta värde skapas det en kopia av inom den processen. Så fort processen kört klart förstörs den kopia av värdet som den haft. Denna metod är inte så bra om mycket data ska användas, då mycket minne kommer att gå åt till att hantera alla kopior. (Microsoft, 2009a)
Det andra sättet är byRef (by reference) som innebär att attributet som skickas in till processen är en referens till det faktiska objektet. Även i detta fall så skapas det en kopia på objektet, den stora skillnaden är att kopian refererar till det faktiska objektet i minnet. Detta innebär att om du ändrar i kopian så kommer även objektet som kopian refererar till att få dessa ändringar. Detta sätt är smartare att använda sig utav när mycket data används, då minnet inte behöver ha era kopior av objekten. (Microsoft, 2009a)
I detta fall så hade byRef varit att föredra då många variabler och attribut ska till processerna. Dock så kan inte trådar ha byRef som parameter utan kan enbart ta emot ett objekt som byVal.
2.9 Multipla attribut till trådar
Eftersom programmet kommer att hantera relativt många attribut så måste även trådarna kunna startas med attribut till dem. Det som dock är ett hinder för detta är att en tråd bara kan ha ett objekt som attribut. För att lösa detta kan en paketerarklass (wrapper class) användas, dvs. ett objekt som innehåller alla variabler som ska skickas med som attribut och funktioner som används i objektet. Denna klass kan även innehålla returattribut, dvs. variabler som tråden returnerar till den process som startar tråden. För exempel se bild 2.2. (Microsoft, 2009c)
2.10 Delat minne
Systemet som ska optimeras använder mycket data och många variabler. Dessa variabler skickas till olika processer. En fundering som uppkom var att det kanske skulle bli krävande för minnet och även ta tid och läsa och skriva från minnet. Det som börjades titta på var vad det fanns för olika metoder för att dela minne mellan processer, detta pga. att det inte går att skicka pekare i VB .NET.
Något som insågs var att det fanns några olika metoder. En av dessa metoder kallas för Named Pipe. Denna metod går ut på att en eller era Pipe servrar och Pipe klienter används. Klienterna ansluter mot servern och kan få data från den. Detta används för att få olika processer att kommunicera med varandra, även för att olika program ska kunna kommunicera med varandra. Det visade sig att en server behövde använda sig utav trådteknik för att kommunicera med era klienter, och detta var inte intressant i detta fall. (Microsoft, 2009b) Ytterligare en metod som nns är tekniken som kallas för Sockets. Denna metod använder sig också av server och klient. Men tekniken med Sockets är inte heller intressant, då systemet inte är ett server / klient system. (Microsoft, 2009d)
Det som visade sig var den enklaste och snabbaste metoden var att skapa paketerarklasser som skickas som referenser till processer och som värden trådar.
Kapitel 3
Optimering av prestanda
3.1 Inledning
Modulerna beräknar stora mängder data, läser och skriver till databasen, kallar på lagrade procedurer och skapar ler. Detta kräver resurser från systemet och är tidskrävande. För att kunna utnyttja systemets resurser och minska exekver-ingstiden kommer de utvalda modulerna att analyseras för att ta fram en de-signspeci kation för hur varje modul ska optimeras, så att de även uppfyller alla uppsatta krav.
Parallellism och samtidighet kommer att implementeras i systemet med hjälp av olika ertrådstekniker och synkroniserings metoder som passar bäst för varje moduls uppgift. Detta kommer att leda till att varje modul optimeras anpassat för dennes speci ka uppgift.
3.2 Förberedelser
Modulerna är skrivna i VB .NET. För att kunna börja manipulera och imple-mentera kod i modulerna behövde modulerna kon gureras upp mot ett testsys-tem så att de gick att testköra.
Flertalet rader i databasens konstanttabell behövde ändras för att få systemet att fungera. Tabellen som var kon gurerad för använda det skarpa systemet än-drades till att istället använda testsystemet. Korrekta mappstrukturer ck sedan skapas på testmiljön och kon gurations ler kopierades över till dessa mappar för att få testsystemet att fungera korrekt.
Eftersom modulerna testkörs fristående behövs en kommando rad med argument för varje modul som ska köras. Vilka argument som varje modul kräver ck utredas genom att studera koden. Båda strängarna kräver en anslutningssträng (connection string) mot databasen och varsin debug agga. Den ena modulen behöver även en sökväg till modulens lstruktur och en sökväg till de XML ler
som är nödvändiga.
Efter att testmiljön var uppsatt så skapades ett SQL script som sätter körstatus och lägesstatus till START vilket tillåter systemet att köra samma jobb från jobbkön era gånger. Scriptet återställer även tabellerna i databasen som de var innan testkörningen så att samma jobb kan köras era gånger med samma förut-sättningar. De bärbara datorerna klarade dock inte av att köra den krävande databasen lokalt, utan den sattes upp på en server på företaget.
En tidsräknare implementerades sedan i ursprungskoden och i den optimerade koden för att få fram data genom att mäta exekveringstiden. Tiderna kan sedan användas för att utvärdera hur bra optimeringen sedan presterar mot den gamla versionen.
3.3 Optimering 1
3.3.1 Bakgrund
Modulen är en avräkningsmodul som läser jobb och data från en databas. Mod-ulen genomför därefter beräkningar på inläst data och resultatet skrivs sedan in i databasen. Det nns fyra olika former av avräkningar. Huvudavräkning sker i huvudsak en gång per år för varje kund. Den beräknar hur inspelade pengar ska fördelas mellan olika artister, musiker och producenter. Tilläggsavräkning körs när en ny summa pengar ska fördelas med samma poängfördelning som i den huvudavräkning som den är kopplad till. Efteravräkning körs när förändringar som hittats i inspelning och speltidsregistret skall uppdateras. Manuell efter-avräkning är en efterefter-avräkning som är begränsad till ett speci kt antal album eller inspelningar.
I denna modul görs bearbetning utav data på ett speci kt ställe. Denna bear-betning sker genom att en for-loop kör igenom en stor dataTable med data och bearbetar denna för att sedan skicka resultatet till en tabell i databasen. Det som skall göras för att optimera detta är att för varje loop göra bearbetningen i en egen tråd. På detta sätt bör arbetstiden för denna modul kunna sänkas.
3.3.2 Kravspeci kation
Kraven som nns på denna modul efter optimering är: 1. Skall exekveras snabbare än tidigare versioner.
2. Skall använda systemets resurser eektivare. 3. Skall kunna göra beräkningar i enskilda trådar. 4. Skall använda sig utav en trådteknik.
5. Beräkningarna skall ske snabbare än versionen innan optimering. 6. Skall ha felhantering för trådar.
7. Skall ha synkronisering vid globala variabler. 8. Skalla beräkna korrekt resultat.
3.3.3 Analys
Första valet som gjorts är att använda en anslutningspool. Detta motiveras genom att systemet kommer ha era samtidiga anslutningar till databasen i olika trådar. Genom att använda sig av en anslutningspool undviks tiden det tar att skapa och förstöra anslutningen samt att det inte går att använda sig utav era trådar som samsas om en anslutning. Loopen kommer att skapa en stor
mängd trådar, i det testarbete som används i detta fall används ca 40.000 trådar vid varje körning, vilket kommer innebära att tid sparas med denna metod. Ett annat val som gjorts är att använda en trådpool istället för att manuellt skapa trådar. Detta val motiveras med att det är många trådar som skall ska-pas. Genom att använda en trådpool undviks inte bara tiden det tar att skapa och förstöra trådarna utan ansvar lämnas även över till operativsystemet. Op-erativsystemet fördelar systemets resurser på de trådar som skapats och tråd-poolen har även en maxgräns på hur många trådar som får köras samtidigt, därför undgås att alla trådar skapas på samma gång och belastar systemet för mycket.
För att skicka data mellan trådar och huvudprogrammet används en wrapper klass. Detta valdes pga. att det var det enklaste och eektivaste sättet att dela information inuti samma program. Däremot behövdes någon synkroniseringsme-tod användas för att detta ska gå utan att krockar skulle ske. Synkroniseringsme-toden som valdes är semaphore. Dels för att det är enkla att deklarera och dels för att de är exibla att använda då det går att initiera hur många resurser den har och hur många som skall vara tagna vid initiering. SyncLock har även använts på några ställen där variabler behövde synkroniseras i asynkrona trå-dar, detta pga. att det bara behövdes en enkel låsning av variabler och det bara skulle kunna vara en tråd som använder variabeln åt gången.
3.3.4 Designspeci kation Optimering 1
Modul
Skapa funktioner och variabler:
1. Skapa funktion som initierar en ny trådpool och skapar ett trådpoolsob-jekt.
2. Skapa funktion som ska köras i en tråd och ytta in funktionsblocket från beräkningsfunktionen som utför alla beräkningar.
3. Skapa global semaphore för synkronisering av funktioner som anropas i trådar och initiera den till 1.
4. Skapa global semaphore för synkronisering av felhanteringsfunktioner och initiera den till 1.
Editera funktioner och variabler:
1. Ändra den globala anslutningssträng variabeln till publik.
2. Ändra beräkningsfunktionen så att den skapar ett wrapperobjekt och sedan initierar variablerna i objektet.
4. Lägg till using connection för korrekt användning av uppkopplingspoolen (connection pool) i de funktioner som anropas inom en tråd och gör databasoperationer.
Synkronisering:
1. Synkronisera alla poängberäkningsfunktioner.
2. Synkronisera funktionsanrop till felhanteringen som sker inom en tråd. 3. Lås indexvariabeln i beräkningsfunktionen.
4. Vänta på att alla trådar har körts klart.
Error Class
Editera funktioner och variabler:
1. Lägg till using connection för korrekt användning av uppkopplingspoolen (connection pool) i de funktioner som anropas inom en tråd och gör databasoperationer.
Wrapper Class
Skapa funktioner och variabler:
1. Deklarera variabler som ska skickas in som parameter till trådar
2. Skapa semaphore för synkronisering av parameteröverlagring in i trådar och initiera den till 1.
3. Skapa semaphore för att se till att alla trådar blir klara innan huvudtråden fortsätter exekvera och initiera den till 1.
3.3.5 Struktur
Figur 3.1: Modulstruktur
3.3.6 Lärdom av implementering
När det skulle börja programmeras dök det genast upp problem. Den delen som skulle göras ertrådig anropar era olika funktioner varav många använder sig av en global SQL-anslutning, detta skapade problem då en enda anslutning kommer att försöka användas samtidigt av era trådar. För att hitta en eektiv lösning på problemet, studerades olika metoder för multipla SQL-anslutningar. Vid implementering av synkroniseringen, uppstod det era samtidighetsprob-lem. Några av problemen var att trådar gick samtidigt in i funktioner och ma-nipulerade värdet på en variabel, vilket ledde till att värden skrevs över och att storleken på arrayer ändrades så att trådar försökte komma åt värden utanför arrayrymden. Eftersom modulen är väldigt stor och många funktioner som ar-betar med delade variabler anropas i trådarna, var det svårt att från början se all synkronisering som behövde göras.
3.3.7 Testscenario
Målet med testet är att få fram data över hur optimering 1 presterar jämte mot original modulen. Följande speci kationer ska sättas upp och utföras för att få fram ett godkänt testresultat.
Systemspeci kation Värdsystem
Datortyp: Lenovo z61p
Processor: Intel Centrino Duo T7200 @ 2GHz Minne: 2 GB RAM
Operativsystem: Windows XP 32-bitars Databasserver
Datortyp: Bark-server
Processor: Intel Xeon E5410 @ 2,32GHz Minne: 2 GB RAM
Operativsystem: Microsoft Windows Server 2008 64-bitars Databassystem: Microsoft SQL server 2008 64-bitars
Optimering 1 Förutsättningar
Huvudavräkning Start klar
StopWatch1 Start: Överst i main funktionen Stop: Sist i main funktionen
StopWatch2 Start: Överst i beräkningsfunktionen Stop: Längst ner i beräkningsfunktionen StopWatch3 Start: Innan beräkningsloop
Stop: Efter beräkningsloop Utförande
Steg 1: Starta en huvudavräkning Steg 2: Beräkna tiden för hela modulen
Steg 3: Beräkna tiden för beräkningsfunktionen
3.4 Optimering 2
3.4.1 Bakgrund
Funktionen som ska optimeras är till för att sammanfoga resultat av match-ningar, genom att hämta data från ler som sedan matchas, för att till slut skriva in resultaten i en tabell i databasen. Det är skrivningen till resultatta-bellerna som tar tid och kräver resurser av systemet. Eftersom varje resultat skrivs in rad för rad i ett dataset först och som i sin tur sedan skickas in i sin helhet till en lagrad procedur, kommer det inte uppstå några synkroniser-ingsfel mot databasen. Denna del av funktionen är tidskrävande och kommer tidsmässigt att kunna förbättras avsevärt om era trådar kan fylla resultat-tabellen samtidigt. Det som implementeras för att optimera detta är att varje varv i loopen ska exekveras i en egen tråd, så att de parallellt kan fylla datasetet samtidigt.
3.4.2 Kravspeci kation
Kraven som nns på denna modul efter optimering är: 1. Skall exekveras snabbare än tidigare versioner.
2. Skall använda systemets resurser eektivare. 3. Skall kunna arbeta med era jobb samtidigt. 4. Skall använda sig utav trådpooler.
5. Matchningar skall ske snabbare än versionen innan optimering. 6. Skall ha felhantering för trådar och databas anslutningar. 7. Skall ha synkronisering vid globala variabler.
3.4.3 Analys
Trådpool valdes som trådteknik för optimeringen. Funktionen kör många korta jobb och det är på grund av det som valet föll på att använda en trådpool i detta läge. Eftersom systemet slipper skapa och förstöra trådar hela tiden kommer ytterligare resurser att sparas.
Parameteröverlagringen mellan trådarna och huvudprogrammet görs med hjälp utav en wrapper klass. Eftersom en tråd enbart kan ta emot ett objekt som in parameter är det enklaste och eektivaste sättet att använda sig av utav en wrapper klass för att skicka in ertalet parametrar i en tråd.
använda, då de kan initiera hur många resurser de har och hur många som skall vara tagna vid initiering.
Eftersom delade variabler måste synkroniseras mellan de asynkrona trådarna så att deras värden inte skrivs över kommer SyncLock att användas för att enkelt låsa variablerna och garantera en korrekt hantering av variablerna när de skickas in i trådarna.
3.4.4 Designspeci kation Optimering 2
Modul
Skapa funktioner och variabler:
1. Skapa funktion som initierar en ny trådpool och skapar ett trådpoolsob-jekt.
2. Skapa funktion som ska köras i en tråd och ytta in funktionsblocket som skriver in resultat i ett dataset från funktionen för resultatsammanfogning. Editera funktioner och variabler:
1. Ändra den globala anslutningssträng variabeln till publik.
2. Ändra funktionen för resultatsammanfogning så att den skapar ett wrap-per objekt och sedan initierar variablerna i objektet.
3. Lägg till funktionsanrop till initieringsfunktionen för trådpoolen i funktio-nen för resultatsammanfogning.
4. Lägg till using connection för korrekt användning av uppkopplingspoolen (connection pool) i de funktioner som anropas inom en tråd och gör databasoperationer.
Synkronisering:
1. Lås indexvariabeln i beräkningsfunktionen. 2. Vänta på att alla trådar har körts klart.
Error Class
Editera funktioner och variabler:
1. Lägg till using connection för korrekt användning av uppkopplingspoolen (connection pool) i de funktioner som anropas inom en tråd och gör databasoperationer.
Wrapper Class
Skapa funktioner och variabler:
1. Deklarera variabler som ska skickas in som parameter till trådar.
2. Skapa semaphore för synkronisering av parameter överlagring in trådar och initiera den till 1.
3. Skapa semaphore för att se till att alla trådar blir klara innan huvudtråden fortsätter exekvera och initiera den till 1.
3.4.5 Struktur
Strukturen på modulen ses på bild 3.2.
Figur 3.2: Modulstruktur
3.4.6 Lärdom av implementering
Efter att förarbetet var klart, började optimeringen implementeras enligt design-speci kationen. Det gick väldigt smärtfritt att implementera allt. Eftersom att de funktioner som anropas i trådarna inte skriver eller läser direkt till databasen eller till globala variabler, leder detta till att synkroniseringsproblem inte
kom-Först implementerades funktionen createThreadPoolJob som initierar trådpoolen. Därefter implementerades funktionen mergeThreadJob som körs i varje tråd. Koden som skriver till dataset yttades sedan in i funktionen mergeThreadJob så att varje skrivning ska kunna ske parallellt.
Klassen threadPoolInputData implementerades och de variabler som ska skickas in i varje tråd initierades. Ett objekt skapas i klassen och tilldelar variablerna inargumenten. For-loopen modi erades sedan i funktionen så att den kallar på mergeThreadJob och skickar med objektet med alla parametrarna.
Det kan dock framkomma vissa synkroniseringsfel då trådarna kommer att ha en kritisk sektion (critical section) där de delar samma variabler. När en tråds kritiska sektion exekveras får ingen annan tråd exekvera sin kritiska sektion. Varje tråd får en indexvariabel inskickat, denna variabel måste lagras över till en lokal variabel i tråden för att den inte ska ändra värde under exekveringen. Detta löstes genom att initiera en semaphore i for-loopen innan index sätts, och sedan släpps semaphoren efter att den lokala tilldelningen i tråden har skett. En semaphore initieras innan for-loopen och ligger sedan och väntar på att alla trådar ska blir klara innan den släpps så att programmet kan gå vidare. Inga stora kompileringsfel uppstod vid kompilering och implementeringen fungerade så gott som på direkten.
3.4.7 Testscenario
Målet med testet är att få fram data över hur optimering 2 presterar jämnfört med originalmodulen. Följande speci kationer ska sättas upp och utföras för att få fram ett godkänt testresultat.
Systemspeci kation Värdsystem
Datortyp: Lenovo z61p
Processor: Intel Centrino Duo T7200 @ 2GHz Minne: 2 GB RAM
Operativsystem: Windows XP 32-bitars Databasserver
Datortyp: Bark-server
Processor: Intel Xeon E5410 @ 2,32GHz Minne: 2 GB RAM
Operativsystem: Microsoft Windows Server 2008 64-bitars Databassystem: Microsoft SQL server 2008 64-bitars
Optimering 2 Förutsättningar
Matchjob Start klar och konverterad StopWatch1 Start: Överst i mainfunktionen
Stop: Sist i mainfunktionen
StopWatch2 Start: Innan loop i sammansättningsfunktionen Stop: Efter loop i sammansättningsfunktionen Utförande
Steg 1: Starta Matchning
Steg 2: Beräkna tiden för hela modulen
3.5 Optimering 3
3.5.1 Bakgrund
Denna optimering skiljer sig mot de andra två optimeringarna. Optimeringen innefattar precis som de andra två optimeringarna, att genom implementering av ertrådighet utnyttja systemets resurser så att uppgifterna som skall göras sker på en kortare arbetstid. Men det mesta arbetet som sker i denna del görs inte i VB .NET utan i SQL server 2008 i form av lagrade procedurer skrivna i T-SQL. I ursprungsversionen körs en lagrad procedur som gör uppslag, ska-par temporära tabeller och fyller dem med temporär data. Sedan skaska-par den lagrade proceduren ett ertal ler. Filerna som skapas är nål ler, höstack l-er och nyckel lhöstack l-er. Dessa lhöstack l-er fylls sedan med olika resultat som lagrats i olika tabeller som skapats tidigare. Problemet med den lagrade procedur som nns i ursprungsversionen är att den tar lång tid på sig, eftersom det skapas ett antal ler sekventiellt. Den lagrade proceduren kallar i sin tur på tre olika lagrade procedurer. Dessa skapar varsin typ av ler, dvs. en lagrad procedur som skapar höstack ler, en annan lagrad procedur som skapar nål ler och en tredje som skapar nyckel ler. Det som ska uppnås med optimeringen är att kunna skapa alla tre typer av ler samtidigt.
3.5.2 Kravspeci kation
Kraven som nns på denna modul efter optimering är: 1. Skall exekveras snabbare än tidigare versioner.
2. Skall använda systemets resurser eektivare.
3. Skall kunna skapa de tre olika typerna av ler samtidigt. 4. Skall använda sig av trådar.
5. Funktionen som kör lagrade proceduren skall skapa lerna snabbare än versionen innan optimering.
6. Skall ha felhantering för trådar och databasanslutningar. 7. Skall ha synkronisering vid globala variabler.
3.5.3 Analys
Första idén för att lösa problemet var att leta efter information angående om det gick att skapa trådar i T-SQL och om det skulle gå att starta olika lagrade procedurer och köra dem samtidigt i T-SQL. Efter studerande insågs att det inte går att genomföra det som eftersöktes. Det enda sättet att kunna genomföra det var att dela upp den stora lagrade proceduren i era delar. Då kunde de olika lagrade procedurerna sedan kallas samtidigt i olika trådar från VB .NET
programmet. Därför valdes detta alternativ, det hittades nämligen ingen annan metod som skulle fungera.
Ett annat val som gjordes var att använda manuellt startade trådar istället för att använda en trådpool. I detta fall ska tre stycken trådar startas per loop varv och var och en ska utföra en egen uppgift. Det är inte värt att skapa en trådpool, utan det är smidigare att i detta fall skapa trådarna explicit pga. att trådarna skall utföra olika uppgifter och att antalet trådar är få.
3.5.4 Designspeci kation Optimering 3
Modul
Skapa funktioner och variabler:
1. Skapa funktion som kör lagrad procedur del1 för hämtning av data och uppsättning av inställningar.
2. Skapa funktion som kör lagrad procedur del2 för uppsättning av komman-don.
3. Skapa funktion som kör lagrad procedur del3 för körning av kommandon och beräkning av resultat.
4. Skapa funktion som kör lagrad procedur som skapar höstack ler. 5. Skapa funktion som kör lagrad procedur som skapar nål ler. 6. Skapa funktion som kör lagrad procedur som skapar nyckel ler. Editera funktioner och variabler:
1. Ändra funktionen för skapandet av matchnings ler till att den initierar loopWrapper objekt och sätter parametrar.
2. Ändra funktionen för skapandet av matchnings ler till att den kör en for-each loop som för varje varv anropar de funktioner som kör procedurer för lskapande och anropar funktionen som kör lagrad procedur del 2 för uppsättning av kommandon.
3. Ändra funktionen för skapandet av matchnings ler till att den efter for-each loop anropar funktionen som kör procedur del 3 för körning av kom-mandon och beräkning av resultat.
Synkronisering:
Wrapper Class
Skapa funktioner och variabler:
1. Skapa subrutin som kör på lagrad procedur som skapar höstack ler. 2. Skapa subrutin som kör på lagrad procedur som skapar nål ler. 3. Skapa subrutin som kör på lagrad procedur som skapar nyckel ler. 4. Deklarera variabler som ska skickas in som parametrar till trådar. 5. Deklarera in och ut parametrar till alla lagrade procedurerna som körs i
subrutinerna. Synkronisering:
1. För varje funktion som skapar ler, släpp semaThread om den är satt till 2, stega annars upp intCounter med ett internlås.
Databasen
Skapa lagrade procedurer
1. Skapa lagrad procedur del 1 som hämtar data och sätter upp inställningar. 2. Skapa lagrad procedur del 2 som sätter upp kommandon.
3. Skapa lagrad procedur del 3 som kör kommandon och beräknar resultat. Skapa tabeller
1. Skapa tabell för lagring av kommandon. 2. Skapa separata exporteringstabeller.
3.5.5 Struktur
Originalstrukturen på modulen ses på bild 3.3 och den optimerade strukturen ses på bild 3.4.
Figur 3.3: Original modulstruktur
Figur 3.4: Optimerad modulstruktur
3.5.6 Lärdom av implementering
Efter att analysen av problemet var klar och designspeci kationen var gjord startades implementeringen. Analysen blev omfattande då det var mycket som gjordes i de lagrade procedurerna som rör implementeringen. Efter att doku-mentering och diagramritande över vad som händer och vart det händer gavs en mycket klarare bild över hur problemet skulle lösas. Med dessa kunskaper startades implementeringen. Första momentet var att dela upp den stora la-grade proceduren till era mindre, och efter analysen som gjorts delades den upp i tre mindre lagrade procedurer och en for-each loop. Första delen initier-ar vinitier-ariabler, tabeller och mappinitier-ar sedan upp nätverks sökväginitier-ar till lmappinitier-ar.
databasen som har med objekt som skall matchas att göra. Del tre av lagrade proceduren kör alla kommandon som har skapats i tabellen och tar sedan bort några temporära tabeller som skapats.
För att sedan få allt att fungera som i originalversionen behövdes en for-each loop implementeras. Denna loop kommer att ersätta en cursor som tidigare legat i den stora lagrade proceduren. För att få detta att fungera implementer-ades en SqlDataAdapter som gör en SQL-fråga, lägger in resultatet i ett DataSet /DataTable. Resultatet som nns i DataTable loopas sedan igenom och för varje rad i resultatet läggs variabler som nns i SQL-resultatet in i wrapper variabler-na. Efter detta startas tre olika trådar. En tråd kör en lagrad procedur för att skapa nyckel ler, en annan för att skapa höstack ler och den tredje för att skapa nål ler.
Det som nu görs istället för att bara köra en lagrad procedur är att först köra del ett av den lagrade proceduren. Sedan gör SqlDataAdaptern en SQL-fråga och stoppar in resultatet i en DataTable. Efter detta loopas DataTable igenom och för varje varv startas tre olika trådar som skapar ler. Efter att dessa trådar körts klart körs del två av den lagrade proceduren. Efter loopen är klar körs den tredje och sista delen av den lagrade proceduren.
3.5.7 Testscenario
Målet med testet är att få fram data över hur optimering 3 presterar jämnfört med original modulen. Följande speci kationer ska sättas upp och utföras för att få fram ett godkänt testresultat.
Systemspeci kation Värdsystem
Datortyp: Lenovo z61p
Processor: Intel Centrino Duo T7200 @ 2GHz Minne: 2 GB RAM
Operativsystem: Windows XP 32-bitars Databasserver
Datortyp: Bark-server
Processor: Intel Xeon E5410 @ 2,32GHz Minne: 2 GB RAM
Operativsystem: Microsoft Windows Server 2008 64-bitars Databassystem: Microsoft SQL server 2008 64-bitars
Optimering 3 Förutsättningar
Matchjob Startklar och konverterad StopWatch1 Start: Överst i mainfunktionen
Stop: Sist i mainfunktionen
StopWatch2 Start: Innan skapandet av matchnings ler Stop: Efter skapandet av matchnings ler Utförande
Steg 1: Starta Matchning
Steg 2: Beräkna tiden för hela modulen Steg 3: Beräkna tiden för skapandet av ler
Kapitel 4
Trådhantering i framtiden
Trådhantering är något som är relativt nytt. Det är speciellt under senaste tiden som utnyttjandet av ertrådsteknik på allvar har börjat bli populärt. När processorer utvecklas i en snabb fart och får er och er kärnor så måste operativsystemen och programmen som används också utvecklas för att kunna utnyttja hårdvaran som nns. Dock så nns det en nackdel. Den nya metoden att programmera program med stöd för trådhantering är det få som kan, därför har utvecklingen av ertrådade program varit ganska sval. Nu när det nns så mycket att vinna på att optimera kod med ertrådstekniken så har efterfrågan och intresset ökat markant. Om några år så kommer ertrådshanteringen att vara ännu större. (Computersweden, 2009)
Detta märks även på utvecklingsverktygen. Både .NET och Java har stöd för ertrådsteknik och får mer och mer hjälpmedel för att implementera detta. I Microsoft Visual Studio 2010 Beta 2 så nns era nya verktyg för att imple-mentera, testa och analysera trådhantering. (Sun, 2009), (Microsoft, 2009e)
4.1 Visual Studio 2010 Beta 2
I nya versionen av Microsoft Visual Studio 2010 Beta 2 och tillägget Team System så har en hel del smarta verktyg lagt still. Dessa går under namnet Parallell Performance Tools. En kort sammanställning av några av verktygen gås igenom nedan. (Sha , 2009)
4.1.1 CPU Utilization / Concurrency Analysis
Den visar i en graf med alla kärnorna på y-axeln och tiden på x-axel. Grafen visar hur mycket utav kärnorna som används under en viss tid. Grafen har olika färger beroende på om kärnan är outnyttjad eller upptagen. Syftet med denna analys är att få uppgifter om en viss vald exekveringstid, t.ex. för att se då CPU aktiviteten är låg då det kan indikera på I/O begränsningar. (Sha , 2009)
4.1.2 Thread Blocking Analysis
Syftet med detta verktyg är att analysera exekveringen av varje tråd. Detta är bra för att hitta askhalsar i systemet och synkroniseringsproblem eller I/O problem. (Sha , 2009)
4.1.3 Core Execution / Thread Migration:
Detta verktyg visar hur trådarna schemaläggs i kärnorna. Genom att använda verktyget går det att se när context switch sker, som t.ex. kan slöa upp systemet pga. av cachning. En annan bra användning är att se hur olika tråd inställningar påverkar exekveringen. (Sha , 2009)
Kapitel 5
Resultat
Efter de testscenarion som genomförts kan det konstateras att alla optimeringar har producerat ett positivt resultat och att samtliga optimeringar nu är snabbare än originalversionerna. Varje utvalt kodblock som optimerats exekveras med hjälp av ertrådsteknik och använder nu systemets resurser eektivare, vilket var en del av syftet och målet med examensarbetet.
Tabellerna nedan visar hur mycket snabbare exekveringen är för de optimerade delarna och med dem i perspektiv mot hur mycket snabbare hela modulen har blivit. Optimering för: Modul 1 Hela modulen 12 % Beräkningsfunktionen 42 % Optimering 1 (beräkningsloop) 65 % Optimering för: Modul 2 Hela modulen 25 % Optimering 2 12 % Optimering 3 52 %
Graferna 5.1 och 5.2 visar tidsdierensen mellan originalversion och de optimer-ade versionerna.
Figur 5.1: Resultat modul 1
Vid en granskning av operativsystemets aktivitetshanterare under modulernas exekvering syns det att systemets resurser nu utnyttjas på ett eektivare sätt, detta ses på bilderna 5.3 och 5.4.
Figur 5.3: Aktivitetshanteraren original
Kapitel 6
Slutsats och diskussion
6.1 Slutsats
6.1.1 Fördelaktiga moduler
Resultatet visar att optimeringarna gjorts på väl utvalda kodblock. Samtliga optimeringar utför nu sina uppgifter parallellt och fullt fungerande utan att vara för komplicerade. Detta är en av anledningarna till det positiva resultatet. Om optimeringarna hade införts på fel områden hade det kunnat försämra sys-temets exekveringstid samt bara gjort de mer komplext än vad som är nöd-vändigt. Det måste kommas underfund med att visa ställen helt enkelt är inte bättre att köra ertrådigt. En av aspekterna som kan göra att ett kodblock inte kommer fungera bättre med en ertrådsstruktur är om väldigt mycket synkro-nisering måste sättas upp. Blir det för mycket lås och köer kommer trådar mestadels enbart ligga och vänta på andra trådar.
6.1.2 Eektivitet
Vi kan även konstatera att sysmets resurser används eektivare. När CPU-användningen övervakas under en avräkning eller matchning kan en markant skillnad ses mellan originalversionerna och optimeringen. När originalmoduler-na är under exekvering hanterar operativsystemet fördelningen av arbetet på kärnorna. Eftersom programmet exekveras seriellt kommer programmet bli up-pdelat så att mindre delar exekveras en i taget på den ena kärnan och sen lite på den andra. Dock så kommer kärnorna att arbeta som om de enbart var en kärna. Detta kan ses då summan av arbetsbelastningen på de två kärnorna blir uppåt 100 %, vilket gör att varje kärna enbart ligger på en belastning runt 50 % var. Detta är en av de negativa aspekterna med multicore processorer då mjukvaran
full kapacitet då programmet kan utnyttja sig av multiprocessorns arkitektur. Detta gör att summan av arbetsbelastningen på de två kärnorna blir uppåt max belastning. (Titus, 2005)
6.2 Diskussion
Syftet med detta examensarbete var att optimera utvalda delar på ett be ntligt system som idag nns driftsatt och målet med examensarbetet var att utnyttja servrarnas resurser på ett eektivare sätt. Detta är genomfört och efter testsce-narion som är utförda kan det konstateras att syfte, mål och krav är uppfyllt. Resultatet som uppnåtts är att optimeringarna har eektiviserat systemet och utnyttjar nu servrarnas resurser på ett bättre sätt inom de utvalda delar som valts att optimera.
I och med att trådpooler och anslutningspooler har använts har tiderna kunnat kapas markant samt att .NET ramverket har haft bra klasser inbyggda för att underlätta implementeringen.
Något som skulle kunna snabba upp systemet ytterligare är att optimera era av de lagrade procedurer som nns i databasen. Det är nämligen dessa som använder största delen av exekveringstiden. Skulle dessa kunna göras om så era kan köras samtidigt skulle mycket körtid kunna sparas in.
6.2.1 Omstrukturering av mjukvara i efterhand
Är väldigt komplext och tar mycket tid efter som originalversionen inte är byggt för att klara av att exekveras parallellt. Det krävs verkligen att funktioner och variabelde nitioner studeras för hur de ska ändras. Komplexiteten sjunker om det redan från början är speci cerat för att köras samtidigt.
6.2.2 Väl de nierad designspeci kation
För att utvecklingen av en ertrådsapplikation inte ska ta för lång tid krävs det även att designen av sitt program är väldigt noggrann, då problemen som kan komma att uppstå redan är identi erade.
6.2.3 Att tänka på vid implementering och vilka fel som
kan uppstå
De problem som uppstår under utvecklingen av trådade applikationer är näs-tan alla relaterade till att era trådar vill åt resurser samtidigt eller skriver över värden i delade resurser. Efter som detta problem innehåller publika de-lade variabler eller globala variabler gäller det att under utvecklingen noga ha koll på vilka variabler som en tråd läser och skriver från och vad den har för
inparametrar. Alla de variabler som kommer att beröras på något sätt av en tråd måste utredas om den behöver synkroniseras. (Intel, 2009)
Det vanligaste felet som brukar uppstå under utvecklingen av en ertrådig app-likation är deadlocks. Det nns era tekniker för att undvika att deadlocks sker. Ett av de bästa sätten är att förhindra deadlocks är att undvika att er än ett lås tas åt gången. Oftast är det inte möjligt, och då måste en bra strategi sättas upp för att se till att alla lås tas och släpps i en välde nierad ordning. (Intel, 2009)
Ett race condition är ett annat vanligt fel vilket uppstår när era trådar vill oper-era på samma block av kod och det producoper-erade resultatet blir olika beroende på vilken tråd som når blocket först. Race conditions kan lösas genom synkroniser-ing av kodblocket. .NET tillhandahåller internlås (Interlock) som kan användas för att förhindra ett felaktigt resultat. Både internlås och semaphores gör att trådar ställer sig på kö och väntar på att få tillgång till kodblocket, detta gör att inte era trådar in kan manipulera delade variabler samtidigt. (Intel, 2009) Det är även bra att huvudtråden ser till att den väntar på att alla trådar hinner köra klart innan den exekverar vidare. Om inte detta sker kan beräknad data tappas eller så kan huvudkoden bearbeta inkorrekt data. Fallet löses med en semaphore som ligger och väntar på att alla trådar ska ha hunnit köra klart innan den exekverar vidare.
En viktig punkt när en funktion som kommer att exekveras inom en tråd skapas, är att alltid implementera spårfunktioner i trådar eftersom det är svårt att se hur en tråd beter sig. Det går t.ex. inte att stega sig igenom det kodblock som exekveras i tråden, vilket gör eventuella kompileringsfel som uppkommer svåra att debugga för att hitta den raden eller de raderna som orsakar felet. (Intel, 2009)
Kapitel 7
Framtida arbete
Det nns ett antal olika moment som inte har ingått i examensarbetet, men som vore intressant att genomföra i framtiden.
Ett moment som vore intressant att se resultatet av är att testköra optimeringar-na på system med olika antal kärnor i processorn. Det skulle vara intressant att kunna testa en, två, fyra, åtta processorer och se vad skillnaden i exekveringstid blir. Då skulle körningarna kunna jämföras och granskas om systemet förbättras med antalet kärnor eller om t.ex. synkronisering gör att den inte kan utnyttja alla kärnor.
Något mer som skulle kunna göras i framtiden är att fortsätta med optimeringar-na på de andra moduleroptimeringar-na i systemet. Rapporten är tänkt att kunoptimeringar-na fungera lite som en handbok för hur fortsatta optimeringar med hjälp av trådteknik ska kunna göras.
För att eektivisera systemet ytterligare skulle det kunna byggas om lite. Sys-temet idag använder sig av en arbetskö, denna arbetskö kontrolleras varje gång programmet startar och börjar då arbeta med jobben en efter en tills det är tomt i kön. Det som skulle kunna implementeras för att eektivisera detta är att ha en köhanterare i en egen tråd som ligger och väntar på att jobb ska läg-gas i kön. När ett jobb sedan läggs in i kön fördelas jobbet sedan till en egen arbetstråd som utför jobbet. På detta sätt kan era arbeten köras samtidigt. Som exekveringstiderna ser ut just nu så är mycket utav tiden lagrade procedurer som körs på SQL-servern. Dessa lagrade procedurer skulle kunna ses över för att kunna eektivisera dem eller bygga om dem så era kan göras samtidigt i olika trådar. Skulle lagrade procedurernas exekveringstider kunna kapas skulle även modulernas exekveringstider kunna kapas en hel del.
Litteraturförteckning
Computersweden, Idg. Flertradad programmering inget for nyborjare. http: //computersweden.idg.se/2.2683/1.112097, November 2009.
Intel. Multi-threading in the .net environment. http://software.intel.com/ en-us/articles/multi-threading-in-the-net-environment, November 2009. Joshi, Bipin. Using connection pooling in ado.net. http://www.codeguru.
com/csharp/csharp/cs_network/database/article.php/c14885__2/, Novem-ber 2009.
Liberty, Jesse. Programming Visual Basic .NET. O'Reilly, 2003.
Microsoft, Corporation. Argument passing byval and byref. http://msdn. microsoft.com/en-us/library/ddck1z30(VS.71).aspx, November 2009a. Microsoft, Corporation. How to use named pipes for interprocess communication
in visual basic .net or in visual basic 2005. http://support.microsoft.com/ ?kbid=871044, November 2009b.
Microsoft, Corporation. Parameters and return values for multithreaded pro-cedures. http://msdn.microsoft.com/en-us/library/wkays279(VS.71).aspx, November 2009c.
Microsoft, Corporation. Socket class. http://msdn.microsoft.com/en-us/ library/system.net.sockets.socket.aspx, November 2009d.
Microsoft, Corporation. Using threads. http://msdn.microsoft.com/en-us/ library/aa289523(VS.71).aspx, November 2009e.
Sha , Hazim. Visual studio 2010 beta 1: Parallel performance tools overview. http://blogs.msdn.com/hsha /archive/2009/05/18/ visual-studio-2010-beta-1-parallel-performance-tools.aspx, November 2009. Silberschatz Galvin, Gagne. Operating System Concepts. John Wiley & Sons,
Inc., 2005.
Sun. java.lang class thread. http://java.sun.com/j2se/1.4.2/docs/api/java/ lang/Thread.html, November 2009.
