Navigate Into Success: NAV performance part 3: Azure VM configurations

[Blog bot]

Источник: http://vjeko.com/nav-performance-par...configurations
==============

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:

• A2
• A7
• D2
• DS13
• GS3

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.


Business Processes

First group of test is again the business process ones, those that show the best how NAV performs overall:



Honestly, should this chart have looked any different, Azure wouldn’t be worth it salt. This chart is as consistent as it is expected.

A7 is fairly slow, and you can see a gradual improvement in performance as you move to D and then G tiers. Each of the higher tiers comes with faster processors, faster memory, and faster disks. And it shows. Improvement is almost linear and it reflects both SQL and NST performance.

If you ask me, this is very reassuring, because you can easily estimate how far you need to go with resources, and then how much it would cost to get specific performance you aim for.

Let’s take a look at another group of tiers here, the A2, D2, and finally P11 SQL tier. It truly doesn’t belong here, because for the price of one month of a P11 database you can run an A2 and D2 virtual machines for three years and then some. However, from performance stance, I simply want to put things into perspective here.



What do we see here? Well, to start with, we see that A2 or D2 or similar machines should not be considered for production use of NAV. Maybe for demos, but then not for sales demos.

What about P11, then? Well, it sits somewhere in between A2 and D2 in terms of performance, however, there are major differences.

First of all, all other configurations in this test were single-machine configurations. There is one simple issue with all Azure configurations, and it’s called latency. No matter how well you configure your virtual network and resource groups and how premium your storage or disks are, latency will kick in and will add up to significant lags on large numbers of operations.

Now, while it may seem that 80 seconds is a lot for number series assignment, keep in mind two things. First, it’s 20.000 number series assignments, and assigning number series is not a cheap operation in terms of database utilization – assigning a number has several roundtrips between NST and SQL, and this P11 performance here isn’t all that bad. Also, roughly 75 seconds to post 100 sales orders and 100 purchase orders and do complete inventory costing and cost posting for them isn’t all that bad after all. There’s much more to SQL Azure, and we’ll see that in the next post where I round up multiple SQL Azure tiers.

Good, now that we have seen that all Azure VM sizes come with bang for buck proportional to the amount of resources crammed into specific VM sizes, let’s take a look at another group of test.

SQL Server Pieces of Cake

The following group of tests addresses SQL and specific aspects of SQL performance at those tasks where SQL was designed to kick ass. So let’s see how Azure VM resources influence SQL Server behavior under the NAV hood.



Again, very consistent story. You need more, you pay more and you get more. It’s really amazing how this chart shows consistent performance of Azure VM infrastructure – it is far more consistent than the on-prem numbers I got while measuring bare-metal performance.

And it makes sense – my local machines were not laboratory-grade equipment. They ran other software, not at the time of the test, but they were not clean, dedicated installs for the purpose of testing. However, here, on Azure, these were dedicated installs, all exactly the same to the last bit of data, and they show that Azure, at least in the new Resource Manager deployments, provides predictable, dedicated performance of as much hardware as you decide to buy.

Let’s take a look at the other three.



Now we are talking business. While A2 obviously shows all the weaknesses of not enough memory and not-fast-enough disks to cope with paging, P11 shows that when operations are not affected by latency, SQL Azure performs pretty well under the hood.

SQL Server Stunts

And finally, we get to the SQL Server’s “don’t do this at home” category. These tests are designed to expose weaknesses in NST-SQL communication and to show how well the system performs under pressure it wasn’t designed to sustain.

First, the A7, DS13 and GS3 group:



And again, the same reassuring consistency. My on-prem configurations didn’t show such consistency, not by far.

These tests put pressure on SQL network and NST, so latency should also play some role in here. Let’s see how well the other group behaves here:



Well, A2 and D2 show the same consistent behavior as any other VM configuration. However, the P11 database shows some strange and honestly, unexpected behavior.

The UniqueRead test is difficult for any configuration, so I’ll skip that one. Similar with RandomVendorRead – this one is not difficult per se, it’s only something you’d not want to do with SQL Azure. Same with CursorRead.

However, the GUID test surprises me. This test puts pressure specifically on the SQL storage and indexing mechanisms, but it measures pure raw SQL performance, there is barely any latency here. And yet, it seems that SQL Azure at P11 level is barely able to cope with a bunch of GUIDs.

Again, this is not to say that SQL Azure is bad here, it simply tells you what SQL Azure is not designed to do. You should never really create a clustered index over a GUID field, and SQL Azure apparently stresses this out as loudly as possible.

And yet, it’s a very expensive database tier, it should be able to handle storage better than a lousy A2 box.

Conclusion

Forget about P11 here. The only reason I put it here is that it showed such a good performance as compared to other SQL Azure tiers that I could run it head-to-head with at least some VM configurations without reducing the number of iterations per test.

Let’s talk about what these tests really were about: Azure VM behavior. As you can see, the behavior is consistent, proportional to hardware sizes, and best of all – predictable.

While all these numbers are not really on par with beefed up on-prem configurations, they don’t need to be. They provide predictable performance, and I dare educated-guessing here – predictable scalability. It’s much simpler to scale Azure VMs than it is local hardware, and that’s where Azure really excels.

I had no clue that the new Resource Manager feature of Azure provides such a great consistency, but having seen this and measured performance in these tests, I feel so much better recommending Azure as a replacement of any on-prem workload. No matter how demanding it is, I am sure there will be an Azure size that will fit you.

So, this concludes the tests of on-prem and Azure VM configurations. What about SQL Azure? Well, that’s a topic for tomorrow.

Read this post at its original location at http://vjeko.com/nav-performance-par...configurations, or visit the original blog at http://vjeko.com. 5e33c5f6cb90c441bd1f23d5b9eeca34The post NAV performance part 3: Azure VM configurations appeared first on Vjeko.com.




Источник: http://vjeko.com/nav-performance-par...configurations