Arenduskeskkonna optimeerimine: Visual Studio lahenduste kompileerimine
21.01.2012 | Gunnar
Mõõtsin huvi pärast Visual Studio lahenduse kompileerimise aegu virtualiseeritud arenduskeskkonna erinevate seadistuste juures. Käesoleval juhul võtsin vaatluse alla failide kasutamise, sest mahukamates lahendustes on failioperatsioonide hulk suur ning ketast probleemid ujuvad teravalt nähtavale.
Keskkond
Alustuseks keskkond, milles katseid tegin. Hosti peal vaatasin algul, et seal oleks piisavalt ressurse ja midagi mahukat ei jookseks, mis kuidagi virtuaalmasina tööd võiks segada. Hosti peal jookseb ühtlasi ka minu töölauakeskkond.
Virtuaalmasin jookseb välise ketta peal, sest hosti peal pole piisavalt ruumi, et sinna kõik virtuaalmasinad ära mahutada, mida tööks või õppimiseks vaja läheb. Suures osas on tehtud ära optimeerimised, mis toodud minu postituses Virtuaalmasina optimeerimine.
Host:
- Masin: Dell Latitude E6510
- Protsessor: Intel i7 (quadcore)
- Mälu: 8GB
- Op-süsteem: Windows Server 2008 R2 Standard (64bit)
- Hyper-V
- Kõvaketas: 120GB SSD
Guest:
- Tuumade arv: 4
- Mälu (dünaamiline): 2048 – 4096 GB
- Op-süsteem: Windows 7 Ultimate (64bit)
- Füüsiline ketas: Western Digital Elements (väline, USB 2.0)
- Virtuaalne ketas: 50GB fikseeritud suurusega virtuaalketas
Katsed
Mina tegin katset kolme erineva keskkonna seadistustega. Katsejäneseks oli täpselt sama lahendus ilma igasuguste muudatusteta. Seadistused Visual Studio lahenduse osas olid sellised:
- Lahendus virtuaalmasinas – lahendus asus virtuaalmasina enda kettal.
- Lahendus mälukettal – lahenduse kataloogi asukohaks oli mäluketas, mille tekitasin RAMDisk tasuta versiooni abil. Failisüsteemi formaadiks oli pakkimise toeta NTFS.
- Lahendus SCSI kettal – lahenduse kataloog asus virtuaalsel SCSI kettal, mis füüsiliselt paiknes host-keskkonna süsteemikettal.
Kõikide katsete korral oli keskkond sama (see tähendab seda, et ei jooksnud ühegi katse jooksul rohkem või vähem programme kui teiste korral).
Mõõtmised viisin läbi sellise vahendiga nagu Process Monitor. Process Monitori seadistused leiab Arik Boznanski postitusest How to Check How Many Writes Are Done While You Build?. Mind huvitas antud juhul failide kasutamise aeg ehk siis see, kui palju kulub aega failidega seotud operatsioonidele erinevate seadistuste korra.
Tulemused
Tulemused, mille mõõtmised andsid, on toodud järgneval graafikul.
Virtuaalmasinas toimuv kompileerimine ei pane mind imestama – üle USB 2.0 väline ketas ja sellele veel Hyper-V overhead otsa. Küll aga paneb mind imestama see, kui suur on overhead mälu virtualiseerimisel. Hosti SSD peal andis virtuaalne SCSI ketas umbes samad tulemused, mis guesti peal mäluketas. Ometi on SSD kordi aeglasem kui arvuti mälu otse hosti peal oleks mäluketas arvatavasti esikohal.
Lühidalt võtaksin tulemused kokku selliselt:
- fikseeritud suurusega virtuaalketaste jõudlus on parem kui dünaamiliselt suurenevatel virtuaalketastel,
- Hyper-V lisab oma paraja panuse nii mälu kui ketta virtualiseerimisel,
- virtuaalmasina hoidmine sisemisel kettal annab paremad tulemused kui tavalised välised kõvakettad,
- virtuaalmasinas jooksva mäluketta ja SSD peal hoitava virtuaalse SCSI ketta jõudlused on umbes samad.
- 99% aega kulub kompileerimise käigus lahenduse koosseisu kuuluvate obj ja bin kataloogide peale (igati loogiline, sest obj kataloogis ehitatakse kompileeritud failid valmis ning bin kataloogi salvestatakse kõik tulemuseks saadud ja projektides viitatud teegid).
NB! Need on vaid minu järeldused antud katse põhjal ja katse on täiuslikkusest päris kaugel. Kindlasti annab optimeerida veel paljut ja kui kellelgi mingeid häid edulugusid leidub, siis olen igati huvitatud nendest.
Lõpetuseks
Kettaoperatsioonide jõudlus muutub lahenduse kasvades järjest olulisemaks kuni ühel hetkel teravdub probleemiks. Et järjest enam on arenduskeskkonnad virtualiseeritud, siis peame arvestama ka virtualiseerimiskihtide eripäradega. Samuti peame arvesse võtma vahendid, mida me kasutame ja mis meile on tööl kasutamiseks antud.
Jõudluse probleemide tekkimisel ei pea tingimata hakkama uut rauda muretsema – tihti aitab see, kui asju veidikene ümber mängida. Selleks tuleb lihtsalt leida lahendused, mida proovida ning äärmiselt oluline on mõõta, et saada selgemaks probleemi olemus.
Virtuaalsete ketaste korral saime me tulemused, mida algul ehk oodata ei osanud. Oli selge, et puhtalt virtuaalsel raual välisel kettal jooksev kompilatsioon on aeglaseim. Kuid see, et mälukettast parema jõudluse saime hoopis SSD ketta otsas virtualiseeritult, oli natukene üllatus küll. See rõhutab jälle kui olulisel kohal on mõõtmised jõudluse probleemide lahendamisel.