How can it be so slow? Many Dynamics 365 for Finance and Operations developers are struggling with performance issues in the development environment. Using the code editor, building the project, starting the application and debugging seem to take forever, consuming time and money.

In this article I will describe how to improve the performance of both Azure hosted and local development environments, while still optimizing the cost of the system.

What is required for good performance?

The key for improving the performance is to understand what causes good or bad performance in the dev environment. Already in AX2012 the disk system performance was the most important factor, and most common bottleneck in the overall system performance. This hasn't changed in D365FO, but the characteristics of the development system have changed.

In AX2012 the source code was stored in the database, so the database performance was critical in development. In D365FO the source code is stored in tens of thousands of files in the file system, in AOSService/PackagesLocalDirectory folder. Having quick access to these files is crucial for the performance.

So, let's have the whole server running on SSD disks, right? If you can, that's definetely a good option. But SSD disks can be expensive. So you might want to put only the source code and the application binaries on SSD disk, and run the OS and other stuff on more affordable regular disks. In the next chapter I will describe how to set this up on Azure hosted VM and a local VM.

What about RAM and CPU, then? You need to have enough of both, but actually you don't need that much. 16 GB of RAM and 4 CPU cores can be enough in a development environment. And if you have 32 GB of RAM, you are definetely doing well. SQL Server will use as much memory as it can, so you must set a limit for it. In SQL Server Management Studio, right click your server in the Object explorer and go to Properties - Memory. In dev environment you should give about 50% of the total RAM for SQL Server.

Set up SSD disks in the dev environment

Let's look on the different types of D365FO development environments, and how to set them up to use SSD disks.

Cloud hosted environment

These environments are deployed from Lifecycle Services into your Azure subscription. You can choose the VM size and adjust the VM to achieve optimal performance. You must choose a DS series VM in order to use Premium Storage (SSD) disks. DS12v2 (4 CPU cores and 28 GB of RAM) is a good choice, DS13v2 (8 cores and 54 GB RAM) is an overkill with twice the price.

If you use DS12v2 with 3 x 128 GB SSD disk, the price is still quite low but the performance is much better than with standard disks.

In Disk space configuration, select 3 disks and disk size 128 GB. This will make the system use P10 disks which cost about 16 EUR / month per disk.

In the deployment setup, in Disk Space Configuration, select Premium Storage.

In Managed Disks, select None.

If you want to be even more cost conscious, you use reduce the number of disks to 2. Or you could deploy the environment on Standard storage, then add additional Premium Storage disk and move only the AOSService folder to the new disk. But the smaller and cheaper Premium Storage disks have slower performance so you will have to test if the performance is acceptable to you.

Moving AOSService folder to another disk is described in the next chapter.

Downloadable VHD

If you run the VHD locally on your laptop, you usually don't have much choice on the disk system - you use what you have. But if the VM is hosted on a separate host in your company network, you can choose to run the VM on normal hard disk (SSD) but attach an additional small SSD disk to it. 15 GB should be sufficient for us. Of course if you can afford to run the whole VM on SSD, it's even better, but having the source code and the binaries on SSD is the most important thing.

The dev VHD is set up in a way that everything is running on C: drive. In order to move the source code to the SSD drive, you need to change some settings in the system. Here we assume that your SSD drive is mapped as E: drive.

1) Stop following services:

• - World Wide Web Processing Service
• - Management Reporter 2012 Process Service
• - Microsoft Dynamics 365 Unified Operations: Batch Management Service
• - Microsoft Dynamics 365 Unified Operations: Data Import Export Framework Service

2) Move folder C:\AOSService to  E: drive

3) Open RegEdit and find HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics\AX\Development. Change the value of DefaultConfig key to point to E: drive instead of C: drive

4) Find registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynamicsAxBatch. Change the value of ImagePath to point to E: drive instead of C: drive

5) E:\AOSService\PackagesLocalDirectory\Bin\DynamicsDevConfig.xml - do a find and replace, changing C:\AOSService to E:\AOSService

6) E:\AOSService\webroot\Web.config - do a find and replace, changing C:\AOSService to E:\AOSService

7) In IIS manager, go to Sites - AOSService - Advanced settings and change Physical path to E:\AOSService\webroot

8) In IIS manager - Sites - Applications, change Physical path of Product configurator from C: drive to E: drive

9) On the Desktop, change the AdminUserProvisioningTool shortcut to point on E: drive instead of C:

Restart the computer to make sure that all changes will become effective.

Microsoft managed environment (Sandbox tier 1)

You get one of these with the D365FO subscription, and can buy more as add-ons. These environments don't seem to have performance issues, and are already running on SSD. In addition to that, you don't have any control over the server setup, so we will not discuss them in this article. 

Conclusion

Boosting the performance of the D365FO dev machine is a relatively simple task. It might add some cost, but the added developer productivity should justify using SSD in most cases. 

Happy development!