Got a call the other night from a friend asking where to start when it comes to troubleshooting a slow AX implementation? Immediately, I started asking him about the hard disk. Suddenly, he asked me about why this was so important for AX performance tuning. And immediately it hit me. If I were new and just starting out in the AX world, this would be pivotal information for my growth and development. Let’s explain why here.

The Hard Disk has always been the slowest part of an Operating System

Practically every known software solution has some component of performance tuning that centers upon minimizing the disk – SQL Server, Exchange, Windows, IIS, Sharepoint tries to speed up the application by reducing the disk operations. This is because the disk is the slowest part of the operating system. Thus, the most common culprit is the disk.

The most common culprit isn’t the only culprit.

It almost goes without say but just because disk access is usually involved in slow performance doesn’t mean that it is the only cause of slow performance. Unfortunately, processor, ram, bad code – all of those can cause issues also. It’s just that starting at the disk is the most logical point.

So, now, let’s take a real live example to see how to review AX performance even without looking at just SQL Server.

First, when you troubleshoot disk performance, you need to ask some critical questions:

It’s all about IOPS and response time. In other words, we need to figure out how many requests the disk can handle per a second from the perspective of the operating system. A good starting point for an idealistic view of what a disk can handle is the vendor site. Also be sure to get a response time metric.

Second, we need to apply a formula to see if our disks are performing anywhere near the disk specifications. Here all that I’ve done is use Resource monitor to monitor the response time. Very often, when you see slow times, you’ll see outrageous numbers here that can then be correlated with high counters.

If you notice here, I didn’t show you SQL server which is where most people go to solve troubleshooting problems. Indeed, you can solve a great deal of issues within sql server, but as you can see here, file based loading on disk is often a huge concern for performance. Bottlenecks here will cause issues and the AOS uses the disk a lot. There is obviously a lot more that I could have mentioned when it comes to disk, but the important point is to know where to start looking. So many times, I’ve found slowness to be caused by just simply looking at disk performance of the AOS itself. It will serve you well to keep this in mind when you are solving a troubleshooting issue.