web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Funny you ask John but…

(0) ShareShare
ReportReport
Posted on by 170

Yes, we are experiencing annoying Dynamics AX Performance problems!

You wouldn’t believe how many times I have heard this phrase in my 13 years’ experience working on AX implementations. And guess what? I know for a fact that in 90% of the time this statement is actually not true! So why is this?

When engaging a customer who is experiencing AX performance problems, it turns out, over and over again, it’s usually not a hardware related issue.

Yes, off course when you try to run Dynamics AX on a machine with, say, 4 GB of memory, it just doesn’t perform.  And no matter what AX or SQL configuration skills you have: it will never perform due to the basic lack of hardware. But be honest: How many AX customers do you know who do not meet the basic hardware needs? Most customers I have engaged have met these requirements and usually also, in the beginning, AX runs fine, performance wise.

No, things start to heat up when the system is actively being used day by day. Users feed data into the tables, are running queries, do the monthly inventory closings and so on. Actually they are doing what they are supposed to do – using AX for registering their business activities. And then after a while, you can just wait for it – the big moaning starts……“Bloody hell, this report takes forever!” or “The invoicing batch hasn’t finished yet – we will be late again!“

This moaning usually worsens over time and all of a sudden we are back at the header of this article: Funny that you ask John…

Working on Dynamics AX Performance over the past years has given me valuable insight into issues like SQL indexing, long running queries, wrong keys, configurations settings like parallel threading, priority batching, table locking etc etc. Many, many settings and parameters are to be considered. And usually this is not the priority of the implementing Partner nor do they have specific consultancy skills in this area. But still : This niche area is where you will find, and solve, most of your problems.  And not in your hardware.

So, after a while I figured that I have a great reply to my valued AX Partners as well as end-customers. Whenever they start to moan and complain, I listen carefully, and let them finish. That’s just basic customer psychology. But in general my reply is:

Dear madam, sir, No, I do not believe you have a AX performance problem! I believe you have an AX knowledge problem which expresses itself as a Performance problem.

This phrase has taken me into many, rewarding, AX performance research and good Partner/Customer relationships and saved many customers a big load of money which would be spend on hardware or another, unneeded, AOS license.

I wonder how my AX Performance thoughts are by others... :), are you experiencing the same? So, fellow AX Professionals, I am curious, let's hear it please,  

Happy tuning,

John Aalders

*This post is locked for comments

I have the same question (0)
  • Klaas Deforche Profile Picture
    2,433 on at

    I agree with you when you say: "I believe you have an AX knowledge problem which expresses itself as a Performance problem. ".

    It is true that most of the time AX installations are undersized. However not much thought is given to performance when developing, although there are great tools like the tracing cockpit to do something about it.

    Also, although many problems are caused by bad code, the most important element for performance is not the AOS but SQL.

    You can't always blame a developer for not coding well either because data can change considerably over the course of an implementation. The performance of things like indexes are greatly influenced by the data that's in the system. Even some SYS code doesn't perform well if you have 1m customers for example.

    I would recommend to everyone using the tracing cockpit with the "bind parameters" checkbox on, then take those SQL statement, run them in SQL Server and look at the execution plan. After a while you'll be solving performance problems in no time.

    Edit: by the way, if you want to share your blog posts with the community, send an email to dlcommed@microsoft.com.
  • Verified answer
    Drumboss Profile Picture
    170 on at

    Thanks for the helpfull insights Klaas, I have taken your advice with regards to the blog. Greetings, John

  • ARPIT CHAVHAN Profile Picture
    4,359 on at

    I really liked your post :)

  • Drumboss Profile Picture
    170 on at

    Thanks Arpit :), I realised that it should be in the BLOG section. I have asked for a blog recommendation. Cheers John.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans