Dynamics AX Trace Parser (Quick Trace tool)

Description

The AX Quick Trace tool provides the ability to capture a trace of the X++ code being executed without needing the Dynamics AX client. 

• As soon as you start AX Quick Trace a new trace will start running.

• After you have stopped the initial trace you can change the trace output location and start a new trace.

1. Start the trace parser.

• If it’s the first time you run it, you will need to select File > Register Database. Type the name of a SQL server and the name of a new database *that does not yet exist* (not your AXDB) and click OK. The trace parser will create the database with that name and set up the tables it needs.

2. File > Import, pick the *.etl files you just captured or plan to analyze.

3. Start analyzing

• All traces are stored in one file.  You will see the client trace (ax32.exe) and all the server traces (ax32Serv.exe) in the Session lookup.
• The server session that is typically analyzed is the one with the largest Inclusive time, RPC count and Database calls.
• The other server sessions are there for items such as security and batch processing.  These items are not always analyzed and can be considered as needed.
• Select the AX32.exe session.
• This trace shows you all the client side method calls.
• Go to the X++/RPC tab.

You can include Name filters to target particular areas.  This filter allows wild carding, such as AssetProposal* that will show all methods that start with AssetProposal.

• Reduce your RPC counts as much as possible.

In general RPC count reduction should be a primary target for improvement.  An RPC call is expensive and becomes a larger issue once latency is considered in a multi-machine and multi-site production environment where the tier calls become slower.

Remember, the guidance is no more than 8 RPC calls per user interaction.  A user interaction is a button click or a selection change, etc.

• First sort by Exclusive RPC calls and see what’s causing issues.

Exclusive calls will show you all RPCs that the method generated only.

• Then sort by inclusive RPC calls and see what’s causing issues.

Inclusive calls will show you all RPCs that the method generated and all the methods that were called by this method generated.

• Then Exclusive duration, Inclusive duration, etc.
• Select AX32Serv.exe session.  Remember to choose the one as noted above in the session description.
• This trace shows you all the server side method calls and the SQL statements.
• SQL server is the one piece that is not currently scalable.

That means that even though AOS scaling can improve performance, the SQL performance can’t be improved this way.

That is why it is important to look at your SQL counts and improve them as best as you can.

• First go to the SQL tab.

Sort by count first and see which statements are called the most.

Make sure the queries are selecting data based on alternate keys to ensure the kernel record cache can be utilized where possible.

Keep in mind that aggregate queries are expensive and are not cached by the kernel.

• Then go to the X++/RPC tab.

Follow a similar analysis pattern as noted for the client session above.

4. General items to consider

• AX allows tier access to occur easily and without much restriction. This can cause issues with Client -> Server calls and Server -> Client calls.
• Common system commands you will see in the traces:

ServerUtilLoad : The kernel is caching metadata.  If you see this it is more than likely that you are not analyzing a trace that was taken on a warm system.  The kernel is building the caches and if you run the same trace again the cache building should not occur.

ServerNext : The client issues a SQL statement.

ServerEvalFunc : The client calls a static method marked server or client references an object instantiated on the server.

ServerSetClassLoopDependencies : The client has a reference to an object on the server tier.  Every time the object is referenced an RPC will be encountered.

ClientSetClassLoopDependencies : The server has a reference to an object on the client tier.  Every time the object is referenced an RPC will be encountered.

• If “your code” is in the top couple pages of data for any of the above analyzing metrics you should work to make it better.
• If you see something that is not your code and appears wrong please ask the performance team to look at it or log a bug.
• You can jump to the call stacks causing the calls.
• Look for random ways to make your stuff faster.

Pull from caches instead of doing round trips.

Cut down on how many times the code is called. 

• Code structuring to keep in mind.

Which tier is your code running on?

Which tier will your code be called from?

Which tier is the object on that your code is calling?

• Overall, just look for bad code and fix it.