axStart: Why performance issues hits you’re AX implementation 3 months after going live.

[Blog bot]

Источник: http://axstart.spaces.live.com/Blog/...C0A0!263.entry
==============


We al know when the customer is going live, a lot of additional work has to be done. Most of those issues are related to performance. But it is possible to see these troubles long before you are going live. The magic tool is called Long Running Queries.
 
The trick is this:

• <li style="margin:0cm 0cm 0pt;tab-stops:list 36.0pt">From the day the first user is playing with AX start already monitoring his behavior with long running queries. Even when no customizations have been made. You can see the behavior of sorting on non indexed fields and not logical used filters on Form and reports. With this knowledge you can teach the user to use AX the right way. <li style="margin:0cm 0cm 0pt;tab-stops:list 36.0pt">When the first customizations are implemented you start monitoring the users of those customizations. You are able to see the bad queries in your code. Even when the user is not complaining about performance you can see performance issues. Be aware when a query takes 1 second in the demo environment, it can go like hell 3 moths after live.

Example: I make a select for update on the sales line and use in the where class the SalesId and ItemId.  
While select forupdate salesline where selesLine.salesId == ‘829’ && salesLine.itemId == ‘myItem’)
{
salesline…….
selesLine.update();
}

 
AX will use the index with the fields SalesID and linenum. The result is that all SalesLine of that Salesorder are found by the index but the system will lock all lines (pagelock). It will even lock saleslines with a different item. The solution can be add a new index with SalesId and ItemId or redesign the where clause so it will use the existing index 100%. This small example is does not hurt in the beginning but when the customer has 50 lines on a salesorder and 80.000 SalesOrder. Trust me you have trouble.
 
It is also handy to look for deadlocks and warning. (Especially Warnings with code 119, should have you’re attention.  They tell you that there can be table scanning.)
 
NOTE: AOS configuration: turn allow client tracing on Application Object server instance on.
 
I think that also the system administrator of the customer is responsible for checking the results of the log. Analyzing the results is still the responsibility of the partner. Also clear the log when you have solved some performance issues so you are for sure there are gone.
 


 

Источник: http://axstart.spaces.live.com/Blog/...C0A0!263.entry