Best Practices: Performance Optimizations
Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
This section has some hints on how an application can be optimized for better performance. This topic also contains a list of the best practice checks for performance. For more information, see the following topics:
Design for Performance
Design your application for performance and functionality. Use a good data model, and use the paradigms of MorphX (copy what has already been done). The features of MorphX are built for optimized performance.
Keep in mind the following issues when you create your design.
Network setup:
The network that connects the client to Application Object Server (AOS) is slow. It is more efficient to make a small number of calls that transfer a large amount of data than it is to make a large number of calls that transfer a small amount of data.
The network that connects AOS to a database server is fast, but it is quicker to keep calls in the AOS than to call over the network.
Database servers are usually high-end and fast, but a single database server serves everyone, and represents the traditional performance bottleneck in the application.
Execution of X++ code:
All X++ statements are fast, but they run faster as CIL than they do in interpretive mode. If your X++ code runs on the AOS, then it can run as CIL.
Creation of objects is more time-consuming, but still fast.
Database-related statements depend on the database design and load. Usually, selects are faster than inserts, inserts are faster than deletes, and deletes are faster than updates.
Calls between tiers (client/server) are slow.
Method calls are expensive. Try to reduce the number of calls. For example, do not call the same method several times if you can store a value from the method and instead use that value.
When you design, implement, and test for performance, use a database with a realistic number of records (millions) in the various tables in the database, a realistic number of concurrent users (hundreds), and a realistic configuration of network, clients, and servers.
Best Practice Checks
Microsoft Dynamics AX conducts specific best practice checks for performance. For information about how to set the options for best practice checks, see Best practice parameters.
The following table lists the best practice error and warning messages and how to fix the errors.
Message |
Message type |
How to fix the error or warning |
|---|---|---|
Table is missing Clustered Index |
Warning |
Using clustered indexes to organize your tables can lead to large gains in performance, but do so carefully. For more information, see Clustered Indexes. |
Table is missing Primary Index |
Warning |
There are advantages and disadvantages for using indexes. For more information, see Best Practices for Indexes. |
Extended Data Type is set to be right justified, should be set to left justified |
Warning |
Set the extended data type to be left-justified. For more information about extended data type best practices, see Best Practices for Extended Data Types. |
RunBase classes should be able to run on 'Called From' (Ensure pack and unpack are implemented correctly to allow promptPrim to marshal the class across tiers) |
Warning |
The RunBase class is a framework for classes that need a dialog for user interaction and that need the dialog values to be saved per user. For more information, see RunBase Class. |
In This Section
Additional best practice errors relating to tables are described in the following topics.
Best Practice Performance Optimizations: Database Design and Operations
Best Practice Performance Optimizations: General Programming
Best Practice Performance Optimizations: Swapping Arrays to Disk
See also
Designing a Microsoft Dynamics AX Application
Best Practices for Microsoft Dynamics AX Development
Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.