Monday, March 3, 2014

Microsoft Dynamics AX 2012: Client Performance Option

 Microsoft Dynamics AX 2012 includes many UX enhancements, such as list pages, ribbons, fact boxes, preview panes, fast tabs, etc. These UX enhancements can help present relevant information at one place and reduce form switches. However, they come with certain performance characteristics. In this post, we’ll explain some of the issues and how to fix them with Client Performance Options.

Potential issues with Factboxes and Preview Panes

In the following figure, you can see the layout of a typical AX2012 list page, e.g. the Customer list page. In the center of the screen is the customer list itself. On the right side of it you can find a series of Factboxes, which present various information about the highlighted customer, such as its address, recent activities, statistics, etc. On the bottom of the list you can find the Preview Pane, which shows some detail information about the customer.

image

These information can be very helpful if you need to quickly find out some facts about the customer without opening the detail form. However, from a performance point of view, it has the following potential issues:
  • Each factbox and the preview pane is a separate form, so you will incur cost of form initialization (FormInit) and rendering (FormRun) for each and every one of them;
  • Factboxes and preview pane are rendered sequentially one by one;
  • If a factbox is expanded and it includes a  SQL query, such as the 3 factboxes shown in the above picture, each will send the query to AOS and SQL and increase load on the servers. In fact, some of the factbox queries include summary information and are quite expensive from SQL perspective.

 

Client Performance Options

To mitigate these performance issues, there are a few options.
For partners/developers, you can change the form and remove unnecessary factboxes. You should also make sure the query for the factboxes performs well, especially when there are a lot of data and a lot of users running the form.
For users, you can collapse less frequently used factboxes using the ^ symbol on the top right corner of the factbox. When you collapse a factbox, it no longer executes its query, thus reducing impact to SQL server. However, FormInit is still called. You can also Hide the factbox using the rectangle symbol on the left of the ^ symbol. When you hide a factbox, no FormInit or query cost will be incurred. This is a per user and per form setting, i.e. your setting only affect you and only affect this form.
For System Admin, if you want to set up performance settings system wide, open the Client Performance Options form from System Administration\Setup\System:
image
There are 4 options here. You can uncheck the Factboxes and Preview Pane Enabled options to remove them from the entire system. You’ll need to restart the client to pick up the change. After removing factboxes and preview pane, the CustListPage look like the following. You get more screen real estate for the list and it loads faster.

image

There’s also a Timeout setting for Factboxes. If you set it to a non-zero value, it will limit the time SQL server spend on the factbox queries. If SQL server can not finish the query within the timeout limit (e.g. 1 second as shown on my system), the query is cancelled. This will limit the load on SQL server and the response time on the form UI.




AX 2012 - Server Configuration Performance 

Options Review





I wanted to take a little time this fine Friday, and review some of the new options that exists when it comes to the AOS Server Configuration in AX 2012. There are a few new things to point out, really a decent amount of things, and it's important to understand them.



As you can see from the screen shot above, to get started with this review we need to look at the System Administration > Setup > System > Server Configuration. In doing so, a form like the one shown in the following screen shot should appear.



You maybe familiar with this form, basically it list all the AOS instances that make up the current Microsoft Dynamics AX instance your connected to. Further you have some of the more standard configuration options on the right, per select AOS. These include the ability to set Batch schedule times, max batch threads and even if an AOS is meant to be considered as a batch server.

What you may not be familiar with is a little hidden part of this server configuration form. To get to this, as shown in the following screen shot, you must scroll with the right far side scroll bar, as highlighted so you can see Performance Options smart tab.



In doing this, when you expand the performance options, you will notice that there are two main groups. A group, related to such performance settings for 'Settings for All AOS Instances'as well as 'Cache limits for this AOS instance.'

You will notice that when looking at this, and comparing these two main groups, that only the cache limits can has a specific AOS override. Other settings like Error on invalid field access or Maximum number of Tables in a Join are specific to the entire instance of Microsoft Dynamics AX 2012. This means those such settings applies across all AOS(es).



I've highlighted a few options in the above screen shot. You can see that the first highlighted option is the maximum number of Tables in a Join. This limit exists, because with all the great new data models changes in AX 2012, there can be some performance issues. Specifically related to creating queries, calls and the like which could cause a massive amount of joins. The out-of-the-box is 27, and this is one settings that is something I've personally had to change for a few clients already. Be careful with it, it's there to limit for a reason.

Further highlighted we have some of the caches, like the amount of objects in the Global Object Cache. This is the size of the objects keep in RAM, for a Specific AOS. This is also now known as the SysGlobalCache. What's interesting to point out, and very important to understand with these cache point of views, is that these caches are always contained within an AOS. This means there are no cache sharing taking place between AOS(es) that you might have in your instance of AX.

Just because you have the option of overriding the cache values for a specific AOS, and you instead use the global setting, should not imply that the cache's are shared among the AOS(es).

I think, for now this is a good introduction to the Server Configuration within AX 2012, specifically the Performance Options for AOS(es). The key take away's are understanding how to get to these values, how caches act within the context of an AOS, and specific instance wide global settings, like Maximum tables in a join. 

No comments:

Post a Comment