Stuart is an experienced NAV Consultant having worked with Microsoft Navision for 15 years, the last 13 of those as a lead consultant on numerous projects with a large national Microsoft Dynamics partner.
Data Transfer for NAV in Azure
A customer recently approached me asking about putting their Dynamics NAV database into Azure but they were concerned about their connection speeds in their office (a contended broadband line).
Having looked at the available information from Microsoft the only information I could find was on blogs dating back to NAV 2009, which were quite generic. They did however make the useful point that if you’ve got high latency then it does have a major impact on the speed of the system (go figure).
I was a bit more interested in absolutes though, so decided to do some testing of my own. I downloaded a fantastic piece of software called NetBalancer (www.NetBalancer.com) that allows you to both monitor and manage your connections.
Having installed the software (and rebooted my machine!) I set it to just show the results from the Dynamics NAV Client (2016 in this case) installed locally on my PC. I then proceeded to carry out some basic tests:
- Initially I connected to the middle tier that was hosted in Azure (SQL was also in Azure)
- Then I navigated to the Posted Sales Invoices and ran a print preview of one of the documents
- I then closed the preview and ran it again several times, as well as print previewing other posted sales invoices.
- I then closed the client and repeated the entire procedure
There is a diagram below of the monitoring of those tests, the basic information that I gleaned from the test is:
- When connecting initially there is a bit of an overhead for a couple of seconds (less than 1 mb/s)
- Navigating has an initial hit - presumably as it caches the navigation pane and downloads the first set of documents to display
- Running an invoice report for the first time is a bit more bandwidth intensive (about 1 mb/s) for a second or two
- Each additional run of that report whether for the initial record or a different record is a lot less intensive (around 120 – 140 kb/s)
Of course, the amount of data that is transferred will be dependent on things like the size of the images in the document (don’t make them massive!), the amount of lines in the document and the quality of the code in the report. Also, this simple test was predominantly downloading and viewing data as a typical user would. If you were to upload a file (such as through RapidStart) you would see a hit on the upload figures.
However, as expected the actual amount of data being passed to the client is minimal and unless several users attempt to print a report for the first time at the same time then day to day use is unlikely to be an issue even on fairly restricted bandwidth.
I find their approach to our relationship very professional whilst being refreshingly realistic. We now consider them to be part of our teamLee Crowhurst, Technical Director