In part 1 of the series I discussed the basic prerequisites for capturing an AX trace. In part 2, I discussed how to collect a trace. In this post I’ll walk you through the process of importing a trace into Trace Parser and show you a few different things I look for when I start analyzing a trace for performance issues.

Install Event Trace Parser for Microsoft Dynamics AX

First, you’ll need to download and install the Trace Parser tool from CustomerSource.

Here are a couple of quick notes on installing the tool:

• .Net Framework 3.5 SP1 should be installed prior to installing Trace Parser.
• The .Net Business Connector is also a required component. It must be installed on the computer where Trace Parser will be installed. Trace Parser uses the .Net Business Connector to connect to an AOS instance so it can display source code for the objects referenced in the traces you import.
• When you first launch Trace Parser you’ll need to register a database for the application to use. SQL Server doesn't need to be installed on the same computer as Trace Parser, but when you launch Trace Parser for the first time you’ll want to be logged in as a user that has rights to create a database for it to use.

At this point I’m assuming you've already collected a trace and installed Trace Parser. Now we’re ready to import a trace and review it.

1. The first thing you need to do is open Trace Parser and select File > Import Trace. Browse to one of the trace files you previously collected, enter a useful description, and click on the Import button. Do this for both the client and server trace files you collected. After each import you should get a “Database import has completed” message.
2. You can review the trace files one at a time, but I find it useful to open a second instance of Trace Parser so I can have the client trace loaded in one and the server trace loaded in the other. I’ll discuss why this is so useful a little later.
3. Once you have the traces open in the tool, the next thing you should do is select the session id you want to review from the drop-down list. If you collected the trace as discussed in the earlier posts, the session list should be limited to just a single session which makes the decision easy.

Call Tree tab:

• The call tree represents all of the activity that happened in the trace. The events are ordered chronologically top to bottom.
• Different shades of red are used to help you see lines that have the highest durations. The darker the red, the longer the duration is for that line compared to other lines at the same level in the call tree.

• Exclusive durations include only the time spent by the code that executed on that line. If the code on that line called other classes as part of its execution, the run time for those additional classes is not represented in the exclusive time.
• Inclusive durations include the time spent at the current level plus all time accumulated by code called from this level.

• Use Ctrl-C and Ctrl-V to navigate between the client and server traces. If you have both the client and server traces open and reach a point while navigating the tree where you see a jump from one to the other, simply copy (Ctrl-C) the line in one trace and paste (Ctrl-V) it into the other to see the associated code on the opposite tier. As a quick example, I browsed to an event in a client trace that had a duration of 172 seconds. This event (ServerNext) doesn't provide any details because it represents a jump to the AOS where execution continued. I copied the ServerNext line in the client trace and pasted it into the server trace. When I did that, it jumped to the associated call in the server trace so I could continue tracking down the long running event which in this case ended up being a SQL statement.  

Client Trace (copy the ServerNext line)

Server Trace (paste anywhere in the call tree tab to get the associated line)

X++/RPC tab:

• I usually start my analysis with Filter by Type and Show Totals.
• You can click on the column headers to sort the contents by any of the columns. Click again to toggle between ascending and descending order.
• Sorting by inclusive or exclusive duration in descending order will show you which classes/methods are consuming the most time in the trace.
• Sorting by inclusive or exclusive RPC calls in descending order will show you which classes/methods are generating the most calls between the client and the AOS. If you see a high number of RPC calls, the code might not be as efficient as it could be. Maybe it’s a form with lots of display methods and no caching or maybe a temp table is being created on the client when it should have been created on the AOS.
• When you find something of interest and you want to see the context in which the code was executed, you can click on the Jump to Callstack button.  This will bring you to the Call Tree tab and highlight the line where the code was executed.

SQL tab:

• The SQL tab will only have data if you’re reviewing a server trace. This is because the AX client always uses an AOS as a proxy for executing database calls.
• I usually start my analysis with Filter by Type, Search by Statements, and Show Totals.
• Sorting by total duration in descending order will show you which SQL statements are consuming the most time in the trace. Do you have the appropriate indexing in place to support the query?
• You may also want to sort by count in descending order. This will show you the SQL statements that execute most frequently. Sometimes the performance problem is caused more by the number of times a statement is called than how long each one takes to execute. Maybe you’re looping through more rows than necessary. Are your AX table cache settings appropriate?

As you can see, this tool provides lots of useful information about how your code is performing. Hopefully I covered enough of the basics to get you started!

For some Trace Parser troubleshooting tips, see part 4.