While NAV has traditionally mostly been a domestic animal, it’s now getting pushed more and more cloudwards. A large number of partners and customers are considering Azure VMs as their platform of choice as it has many benefits over purchasing and running the whole show in your own basement.
So, I have tested several Azure VM configurations to show what A, D, and G tiers bring to the show, and how much those numbers next to tier letters really mean.
These were the contestants:
I chose A7, DS13 and GS3 because they all have fairly similar resources:
The only significant difference here is that DS13 and GS3 use premium disks, while A7 uses standard disks, however there is also some difference in hardware configurations. G tier has much better processors than D tier, which has better processors than A tier.
The other two contestants are somewhat undersized and I used them to check if those configurations can cope with sustained pressure:
And, there is an unexpected guest in this roundup: the DS13 machine with SQL Azure P11. It’s an oversized and unbelievably expensive options, and the reason why I put it here is that it’s the only SQL Azure configuration that can remotely hope to compete with VM deployments of SQL.
On-prem is where NAV has ran for ages, and where it will still primarily run for a while more. So I test several on-prem configurations with different processors, disks, and memory, to see how these configuration behave in scenarios I described in the original post.
I don’t have too many different hardware configurations to test, but I do have those
An i7-3770 machine with two OCZ Vertex4 SSD disks and a Western Digital Caviar this or that, and 32 GB of RAM.
An i7-6700K machine at 4GHz with two Samsung M2 950 SSD disks (at 2.5 GB/s read and 1.5 GB/s write speed), two Samsung EVO Pro 850 (at 500 GB/s read/write), and a Seagate something or other 8TB drive, and 64 GB of RAM.
All in all, I tested these configurations with:
Data and log being on different SSD disks.
Data and log being on the same SSD disk.
Data and log being on the same magnetic HDD drive.
Yes, I have been a lazy blogger lately. With so many people blogging about NAV nowadays, it’s really difficult to come up with original content all the time.
So, I decided to test performance of NAV under various configurations, including on-prem, Azure VM and SQL Azure, and share my findings with you. And while I am writing these lines, there are four machines sweating the crap out under some performance test code I recently wrote.
Upgrade projects are lots of fun. They are full of challenges that keep you busy day and night all the time.
I have encountered a very interesting challenge on my last upgrade project. The object upgrade process was completed, the data upgrade procedure ready to go, but when we started first tests we realized that the data upgrade execution takes some 39 hours to complete just Step 1. Without even bothering to measure Step 2, we realized we need to do something about it. The customer is running a 24/7 business, and cannot accommodate for such a large downtime, just to upgrade data from NAV 2009 R2 to NAV 2013 R2.
Eventually, we got it down to under a second. If you want to learn how, read on.
Marketing is nice as long as it matches the reality. With Microsoft Dynamics NAV 2013, Microsoft has promised a lot of improvements, but how well does NAV 2013 stand the reality test?
Apparently, outstandingly well.
Over the past two days, I have intensively tested NAV 2009 and NAV 2013 through a series of five different tests that measure different aspects of NAV data handling. My conclusion is clear: NAV 2013 is faster than any NAV you have ever seen, including the Classic client on the native database.
Continue reading to find out more about my findings and testing approach.