The purpose of events is to simplify business logic customization while not impeding upgradeability and general extensibility. However, there is one particular class of events that may cause troubles: OnAfter* table events. There are four of them: OnAfterInsert, OnAfterModify, OnAfterDelete, and OnAfterRename.
If you need them, you must be careful.
SQL Azure is a very interesting service. It’s as interesting as it is misunderstood both in terms of how exactly it works, and what it’s intended to be used for.
First of all, it’s not really the same thing as SQL Server that you install on your box, virtual or physical. It certainly provides the same functionality, and from functional perspective most of things you can do with SQL Server, you can do with SQL Azure. But it behaves in so many different ways that you can’t truly compare them side by side.
Another thing is what SQL Azure was designed for. It’s designed for massive cloud workloads where concurrency is more important than sheer speed. And in that respect it is just brilliant. However, to get most out of it, you have to write and optimize your database access code specifically to take advantage of its features and behavior, otherwise, you simply get performance that can be qualified as mediocre at best.
What happens when you put NAV on SQL Azure? Well, that’s something that you certainly can do – Microsoft does it as well. The thing is – it works. It leaves a bit to be desired if you intend to run heavy processing, but my firm conviction – having tested it and having gone medieval on it with my tests.
Let’s take a look.
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.
Let’s see the results.
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
All in all, I tested these configurations with:
Let’s see the results.
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.
Let venture a little bit out of my .NET and JavaScript comfort zone, and hang around a more formidable beast: SQL. And as you know, SQL comes in many shapes. It comes in shape of your rack server, or in shape of your laptop. But it also comes in shape of clouds. Many clouds.
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.