Hi to all,We have now successfully used the tracing in AX2012. We are currently investigating about a performance problem we have and the trace of AX2012 and Traceparser are very powerfull instruments in such kind of activity.I have a question regarding some information shown in the traceparcer.We have a call through the SysOperationRPCFrameworkSerivce::runServiceOperation --> SysDictClass::invokeStaticMethodIL --> runas(......)
As I've understood here the execution is forced to run as IL (.net).
In the traceparcer the runAs call is shown as ClientEvalFunc, we are on the AOS server, but what does the ClientEvalFunc mean? Will here a roundtrip to the client be done?Our performance problem is that in order to perform the runAs between 20 to 40 seconds are taken, but in the traceparser we don't see what is going on as no other additinal stack trace is shown.Can you please provide some hints or additinal information?See some screenshots in attachement.PS. We are using the traceparcer provided for AX2012 RTM + CU2.Thanks in advanceThomas
I don't think that "Client" in the ClientEvalFunc name refers to AX client - batch jobs even doesn't have any client at all.
The best option is probably to use some .NET profiler. I tried the profiler included in Visual Studio 2010 Premium and it seemed to work well. (Analyze > Profiler > Attach/Detach...)
Martin "Goshoom" Dráb | Freelancer | Goshoom.NET Dev Blog
As Martin said above, using the .NET Profiler is a very valid option - I have included some quick teps below on how to get started using it. Another option during testing would be to turn off CIL execution in the Tools-Options window for the user taking the trace - found on the Development tab in the General section titled Execute business operations in CIL. That way all the code will be run as X++ and the standard trace parser can be used.
Simple steps for using the Visual Studio Profiler
1. Open Microsoft Visual Studio 2010 and get AX to the spot you want to start profiling
2. Go to the Analyze menu and choose Profiler – Attach/Detach and pick the AX32Serv.exe
3. Right-click on the Performance project you should see in the Performance Explorer window in VS (may have to open from menu) and choose properties
4. Pick Sampling and remove two zeros from the sampling interval so that it is 100000 (For smaller length traces remove three or four zeros as needed to get smaller intervals)
5. Go back to AX or wherever and do your task to profile
6. When done, choose to Pause profiling on the window you should see inside Microsoft Visual Studio
7. Go back to the Analyze menu and choose Profiler – Attach/Detach and choose the same ax32serv.exe and Detach (if you hit the Stop profiling link you would shutdown the AOS)
8. Then it will generate a report, and to me the most useful view from the drop down list at the top is Modules or Call Tree...If you look at the functions view you pretty much have to drill down using the Inclusive Samples column because the Exclusive column doesn’t work that great.
thanks for the steps in order to do the profiling. This works well in a dev enviroment but in order to do it on a productive environment, I've seen that there is the possibility to install the VS Profiler as standalone on the AOS, without the need to install complete VS.
I've tried a simple sampling as you describe.
Is there a way to attach source code as well? Sorry my question I'm a newbe in using VS Profiler.
In addition here some usefull links for Standalone Profiler:
Profiling something using sampling with standalone:
You are correct there is a standalone profiler, however trying to run this on a production environment is generally never recommended. With the Visual Studio or standalone profiler there is no way to only profile events from a single client session, which will make interpreting the results very challenging. Switching the code to run back in X++ for a single user and doing an AOS trace from the one client usually works better for any type or production tracing.
I am not sure I understand your question about attaching source code - my only experience using these profilers is that they only work at the function call level and not an individual source line level, but I am not an expert with these profilers by any means.