One frequently noted problem in AX 2012 is the performance of inventory on-hand. The worst part is that while the problem is known, the solutions aren’t. You can try to solve it by guessing and poking around, but you may never discover the true underlying cause.
And it’s also a bit of a naughty beast: here today, gone tomorrow. Then suddenly it comes back to bite you: worse than ever, while your company slows to a crawl and all the best practices you’ve put in place just seem like a complete wast of time!
But what can you do? Well, first off, you shouldn’t sit around waiting for someone from the warehouse to pass by and snidely mention they can’t get anything done on their computer. On the other hand, you don’t want to spend every moment of every day testing your website like a hamster on its wheel. So instead let’s put Alyvix to work. Start it up and let it filter using this mask: ► Company ► Product information management ►Common ► Released products.
It’ll work all day, every day, without a break, and it will even tell us how long the website took to respond after each click or input we asked for.
Once we’ve set the filter to only see those items we’re interested in, we can open on-hand inventory.
And now it becomes really effortless. We can separate out the measurements of the time needed to open our web form into two different days. Immediately you can see two very different stories of performance and behavior. It’s the very same operation, item, and settings, running on AX and DB SQL server…
So, tell me what you think… Oh right, I’ve visualized the problem, but I haven’t really fixed it. True, and this is the point when NetEye agents and a touch of experience digging into the mountain of data they collect comes into play. But here’s where you’ll find the key detail you need: two queries that run poorly, but along with that the entire list of users affected by this problem and when.
But beyond durations, physical and logical reads, and all those features that illustrate just how big the problem is, you’ll also find the priceless query_hash and queryplan_hash, which can show you the precise text and execution plans for these queries.
They might be the stuff of nightmares, but at least you’ll be on the right trail towards really solving the problem. Of course, that’s another story altogether…