De setup
Met de release van D365 zijn enkele belangrijke zaken veranderd met betrekking tot ontwikkelingsactiviteiten.
- In plaats van één ontwikkelomgeving voor alle ontwikkelaars te gebruiken, heeft elke ontwikkelaar zijn eigen ontwikkelserver nodig
- Het gebruik van Visual Studio
- De onmogelijkheid om te debuggen in test/productie omgevingen
De typische setup die we hebben is om één ontwikkel CHE (cloud hosted environment) te gebruiken per ontwikkelaar, per klant. De CHE’s worden ingeschaald op DS12_v2, omdat we vinden dat dit een goede balans is tussen prestaties en kosten. En we moeten er ook voor zorgen dat deze CHE’s automatisch worden afgesloten om kosten te besparen.
Dit leidt tot een paar ergernissen.
- Het kost tijd om een ontwikkelomgeving op te starten voordat je in staat bent om te ontwikkelen
- Als je in de loop van de dag een kleine taak voor een andere klant wilt uitvoeren moet je een andere omgeving opstarten en weer wachten
- Visual studio is fijn om in te ontwikkelen maar kan vrij traag zijn
Hoewel wij alleen CHE’s hebben gebruikt om op te ontwikkelen, levert Microsoft ook een VHD (virtual hard disk) bestand voor on premise implementaties. Je kunt dit bestand gebruiken om ontwikkelservers te implementeren op je eigen hardware.
Ik ben benieuwd of het klonen van deze VHD naar een fysieke harde schijf voor gebruik op dedicated hardware de snelheid en soepelheid van de ontwikkelervaring zou verbeteren, en ik heb besloten een experiment uit te voeren.
Het experiment
Met behulp van mijn eigen ( consumenten) hardware probeer ik een ontwikkelbox te maken voor D365.
Op deze box wil ik twee dingen uitproberen:
- Draai een VM vanaf hier en vergelijk de prestaties
- Kloon de VHD naar de schijf, start direct op in de ontwikkelbox en vergelijk de prestaties
De relevante hardware:
CPU: AMD Ryzen 9 5900X (12 cores, 24 threads)
RAM: 32GB
SSD: PCIe 4.0 NVMe SSD.
Om de prestaties te vergelijken, heb ik twee dingen gedaan.
- Compileer onze (geweldige) C4C ISV oplossing en noteer de tijd
- Open een paar klassen, tabellen en SSRS rapporten om een gevoel te krijgen voor hoe snel Visual Studio reageert
Met de opmerking hierbij dat ik de D365 client niet heb geopend en de prestaties hier niet heb gecontroleerd. Dit is omdat ik voor het opzetten van de omgeving een app registratie in onze Azure AD zou moeten maken, waar ik op dit moment geen toegang toe heb. Dit zou echter een andere interessante benchmark zijn.
De procedure:
Het VHD bestand werd gedownload van LCS en overgezet naar deze machine.
Vanaf hier heb ik een hyper V machine aangemaakt, er 12 GB RAM aan toegewezen, en het VHD bestand aangekoppeld. Hierna kon ik de VM starten.
Met behulp van de instructies in deze link, voegde ik de VHD toe als een boot entry, zodat de PC er direct in kon booten. Dit betekent dat alle hardware alleen door de ontwikkelomgeving gebruikt wordt.
Ik heb geprobeerd de VHD naar de schijf te klonen, maar de machine startte niet in het OS. Dit kan waarschijnlijk verholpen worden met extra moeite, maar ik denk dat de extra prestatieverbeteringen verwaarloosbaar zullen zijn.
De resultaten
- Compilatie-benchmark
| Machine | C4C Compilation time |
| Azure CHE | 08:33 |
| Hyper-V VM | 03:25 |
| Rechtstreeks opstarten VHD | 1:45 |
Zoals je direct kunt zien, zijn de verbeteringen in compilatietijd behoorlijk indrukwekkend.
Het gebruik van de Hyper-V VM halveerde de compilatietijd.
De dedicated machine halveerde de compilatietijd nog eens.
Een screenshot van de machine die hard aan een compile werkt
Mijn theorie is dat de meeste van deze verbeteringen komen door de snelheid van de SSD. Ik heb gekeken naar de prestaties tijdens het compileren en de VM heeft zelfs niet alle toegewezen 12 GB RAM gebruikt. Het processorgebruik is ook nooit hoger geweest dan ongeveer 15%.
Microsoft biedt de optie voor premium opslag voor CHE’s wat de prestaties zou verhogen, maar helaas betekent dit dat je moet betalen voor de opslag, zelfs als de machine uit staat. Dit maakt het een zeer dure optie.
- Visual studio prestatie benchmark
| Machine | VS feel |
| Azure CHE | Langzaam, een bestand openen kan soms wel 20 seconden duren. |
| Hyper-V VM | Snel. Bestanden openen is over het algemeen snel maar soms kan het nog steeds enkele seconden duren |
| Rechtstreeks opstarten VHD | Supersnel! Alle bestanden openen direct. |
In deze benchmark was ik meer geïnteresseerd in het gevoel van de ontwikkelingservaring dan in harde cijfers. Daarom heb ik geen getallen genoteerd, maar in plaats daarvan mijn algemene ervaring met het systeem opgeschreven.
Ik was verbaasd toen ik Visual Studio voor de eerste keer opende op de “Direct boot machine”. Elk bestand dat ik aanklikte opende onmiddellijk. Het voelde eerlijk gezegd als een totaal andere ervaring, en het was zeer aangenaam om te gebruiken.
Nadelen
Hoewel een dedicated hardware setup veel sneller is dan de cloud gehoste omgevingen die we normaal gebruiken, heeft het enkele belangrijke nadelen:
- Het is meer werk om het op te zetten.
- Je moet zelf een Azure AD app registratie maken om de client te laten werken
- Minder frequente updates
- Microsoft ontwikkelt eerst de Cloud Hosted omgevingen, en daarna de on-premise images
- Bijvoorbeeld: Op het moment van schrijven is .25 al beschikbaar om te deployen in CHE’s. De on-premise VHD is nog .24
- Soms bevatten ze bugs die CHE’s niet bevatten.
- Bepaalde features zijn niet beschikbaar.
- PowerBI, Dual Write, elektronische rapportering, taakrecorder
Conclusie
Op dit moment zijn de nadelen groter dan de voordelen, daarom zou ik het gebruik van deze VHD’s nog steeds niet in alle gevallen aanraden.
Echter, als we ooit het punt bereiken dat één ontwikkelmachine gebruikt kan worden voor meerdere klanten (verschillende code- en database), dan zou het erg interessant kunnen worden om een snel presterende machine te hebben om de ontwikkeling te versnellen.