Microsoft Dynamics AX

Master Planning Performance

White Paper

May 2010

Table of contents
Introduction ....................................................................................................................... 3 Reviewing settings and test results ................................................................................. 3
Settings for testing ..............................................................................................................................................................................................3 Test results for finite-capacity job scheduling...........................................................................................................................................5 Test results for infinite-capacity operation scheduling ..........................................................................................................................6

Understanding the parallelism framework ..................................................................... 7

Recommended list size ......................................................................................................................................................................................8

Using finite capacity .......................................................................................................... 8

Bottleneck scheduling ........................................................................................................................................................................................9 Backward capacity time fence .........................................................................................................................................................................9 Additional features ........................................................................................................................................................................................... 10

Addressing customization issues ................................................................................... 10 Troubleshooting .............................................................................................................. 13 Conclusion ........................................................................................................................ 16

2 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Introduction
This document provides an overview of the level of performance you can expect from Master Planning in Microsoft Dynamics AX 2009. It is designed for technical consultants and functional consultants who have some understanding of the code base. You can use this document to: Understand the helper framework so that partners can modify it effectively without affecting concurrency. Explain performance-related user parameters. Troubleshoot performance issues.

Reviewing settings and test results

Master Planning in Microsoft Dynamics AX 2009 comes with out-of-the-box support for parallelism, which means that items at the same level can be independent of each other and scheduled in parallel. As you review the results, it is important to note the scaling that can be achieved with parallelism. The scaling will depend on schedule method (Job/Operation), number of finite-capacity work centers, and other factors. Hardware setup also plays a major role in performance. The results of the singlethreaded run are less significant because they will vary depending on parameters like number of BOM items, number of route lines, and so on.

Settings for testing

The following sections describe the specifications and settings for two trial runs to test parallelism performance. These trial runs are based on finite-capacity job scheduling and infinite-capacity operation scheduling.

Specifications
The following hardware and software specifications are for example only and are not recommended. This scenario purposely uses a lower-end hardware setup to measure scaling performance. Database Server: HP ProLiant DL385 G1 Processor: 4 x 2.6 GHz AMD Memory: 4 GB Disk Drives: Disks: 7 x 146.8 GB @ 10K RPM Disks: 1 x 36.4 GB @ 15K RPM Disks: 2 x 73.4 GB @ 15K RPM Network: 2 x Broadcom NetXtreme Gigabit Ethernet Database Software Settings/Operating System: Microsoft Windows Server 2003, Enterprise Edition Microsoft SQL Server 2005 Service Pack 2 Data Volume: SA6400 controller Array: A Disks: 7 x 146.8 GB @ 10K RPM Log Volume: SA 6i controller (embedded) Array: B
3 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Disks: 1 x 36.4GB @ 15K RPM TempDB Volume: SA 6i controller (embedded) Array: A Disks: 2 x 73.4GB @ 15K RPM

Application Object Server (AOS): Model (SJR2A081) Intel x86 4 x 3.5 GHz Memory: 4 GB Network: 2 x Intel PRO/1000 MT Dual Port Network Connection (Ethernet 802.3) Application Object Server (AOS) Software Settings: Microsoft Windows Server 2003, Standard Edition

Volume
Because master plan runs are dependent on a multitude of parameters, this example does not include a complete list pertaining to volume. However, this example does include details about the number of planned production orders, which will give you an approximate idea about expected performance.

Update phase
Customers who are running Microsoft Dynamics AX 3.x may find the update phase timing on the low side. This is because Master Planning in Microsoft Dynamics AX has three main code paths for the Update phase, including: A. Master plan run without filter and freezing time fence B. Master plan run without filter, but with freezing time fence C. Master plan run with filter In Microsoft Dynamics AX 3.x, code path A is optimized. Beginning with Microsoft Dynamics AX version 4.x, path B is also optimized. It is recommended that the nightly master plan run is done without filter. If you choose to run master plan with filter, the Update phase time on your system will not correlate with the following figures for finite- and infinite-capacity job scheduling. Note: The trial runs were done without filter and without freezing time fence.

Coverage phase
If you run master plan with finite-capacity job scheduling, you will see performance gains even on a single-threaded run. For the finite-capacity job scheduling test run results below, it would have taken approximately 24 hours to complete the coverage phase. This reduction in timing is due to multiple performance initiatives. Some of these initiatives need user interaction in terms of proper setup. For more information, see the chapter titled Using finite capacity.

Futures phase
With Microsoft Dynamics AX 2009, you can expect a significant decrease in futures timing even on single-threaded run, as compared to previous versions of Microsoft Dynamics AX.
4 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

In previous versions, all planned production orders were rescheduled during futures, regardless of whether they were delayed. In Microsoft Dynamics AX 2009, a subset of delayed planned orders is rescheduled during futures, as shown in the following graphic. (Red denotes planned orders that are delayed.)

Planned Production Order: Level 0

Rescheduled during futures

Planned Production Order: Level 0

Rescheduled during futures

Planned Production Order: Level 1

Rescheduled during futures

Planned Production Order: Level 1

Planned Production Order: Level 2

Planned Production Order: Level 2

On-hand stock available for raw materials

On-hand stock available for raw materials

Figure 1. Simplified requirement diagram

Test results for finite-capacity job scheduling

The following parameters apply to the trial run using finite-capacity job scheduling: All timings are in minutes. The number of planned production orders generated during the run was 37K. The bottleneck scheduling feature was not used during these tests. We strongly recommend using this feature if you are running master plan with finite-capacity job scheduling. Table 1. Number of threads Number of AOS List size Update time Coverage time Futures time Total 1 1 50 11 538 114 663 2 1 50 10 347 71 428 3 1 50 9 258 62 329 4 2 20 9 215 46 270 6 2 15 8 185 38 231 8 2 10 8 174 35 217

5 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Test results for infinite-capacity operation scheduling

The following parameters apply to the trial run using infinite-capacity operation scheduling: All timings are in minutes. The number of planned production orders generated during the run was 49K. Table 2. Number of threads Number of AOS List size Update time Coverage time Futures time Actions time Total 1 1 100 29 177 28 35 269 2 2 100 20 109 15 18 162 4 2 100 17 54 8 11 90 6 2 100 17 44 7 9 77

6 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Understanding the parallelism framework

To customize the code and troubleshoot scaling issues effectively, it is critical to understand the parallelism framework. As mentioned in the previous section, parallelism in Master Planning in Microsoft Dynamics AX can be explained in a single sentence: All items at the same level are completely independent of each other and can be scheduled in parallel. At the beginning of the master plan run, all items to be processed are divided into lists. The lists are stored in two tables: ReqProcessItemList is the list header and ReqProcessItemListLine contains the items assigned to a specific list, as shown in the following figure.

Update /Coverage/Futures /Actions

MAIN THREAD

HELPER THREAD

Threads 1..n
Get next list number

Fetch items routine

Block ReqProcess record to make sure only one thread fetches list at a time Get a list header (ReqProcessList record) that has not been marked as processed

Wait for all threads to reach coverage

PROCESS ITEMS AT LEVEL 0 Wait for all threads to finish Level 0

PROCESS ITEMS AT LEVEL 1 Wait for all threads to finish Level 1

Mark the list header as processed

PROCESS ITEMS AT LEVEL 2 Wait for all threads to finish Level 2

Process all items in the list

FetchItems (ReqProcessListLine records) corresponding to the list number

Release lock on ReqProcess record

Wait for process to get pre status

Figure 2. Simplified graphical representation of the parallelism framework As shown in the Fetch items routine process, blocking the ReqProcess record has the potential of placing a significant constraint on scaling. However, it is important to note the following: A. Blocking is done once per list, so the number of blocks is very small. For example, if there are 10,000 items divided into 500 lists, then the blocking is done only 500 times instead of 10,000 times (i.e. the number of individual items). B. Each list contains a number of items that in total will take different times to manipulate. This in turn means that the number of threads trying to fetch a list number at the same time will decrease. Because of these conditions, the list size plays an important role in alleviating the lock contention on ReqProcess record. As shown in the following figure, you can set a parameter while starting a run and set the list size while starting the master plan run.

7 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Figure 3. Item distribution factors in Master scheduling The formula for calculating list size is as follows: List size = Max of (Item distribution factor, 1) * Max of (Number of helpers, 1) Although it may be appealing to set the Item distribution factor to a large value, this methodology is problematic because the average time to process requirement transactions will vary across items. This can be the result of multiple factors. For example, the number of requirements per item will vary, or in the case of finite capacity, there is a significant bottleneck for certain items, and so on. If a majority of long-running items get assigned to a single thread, then there are some threads that will finish faster. These threads will have to stay idle until the rest of the threads finish processing. This will hinder parallelism and result in unpredictable master plan run times.

Recommended list size

The list should be as small as possible, but not so small that it puts severe contention on the ReqProcess record. Because a number of factors influence the list sizesuch as planning parameters, transactional data, and hardwareit is not possible to recommend a standard list size. Instead, it is recommended that you start with a list size of 50 (infinite scheduling) and 20 (finite scheduling) and then adjust the list size until you arrive at an optimum value.

Using finite capacity

When a master plan run is done using finite capacity, the work center scheduling engine runs in a single-threaded node. Therefore, when a thread encounters a work center that needs to be scheduled with finite capacity, the scheduling engine is locked. In addition, other threads that need to process a work center with finite capacity must wait until the thread that has taken a lock on the scheduling engine completely finishes scheduling the planned production order. Obviously, this process has a significant impact on scaling. There are a few performance features that will alleviate the issue, most of which can run in the background without requiring user intervention. However, there are exceptions for the following features that do require user intervention.

8 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Bottleneck scheduling
Every work center has a checkbox that you can select to indicate whether the work center is a bottleneck resource. In addition, the new Bottleneck capacity time fence feature has been introduced on ReqPlan. It is recommended that you carefully examine the routes and mark only appropriate work centers as bottleneck resources. You can also set the finite-capacity time fence to a low value and assign the previous finite-capacity time fence value to the Bottleneck capacity time fence. The combination of [primary work center finite + secondary work center infinite] will provide much better accuracy and performance than [primary work center infinite + secondary work center finite]. Finite in this context indicates a work center that is scheduled with finite capacity due to a finitecapacity time fence or Bottleneck capacity time fence. This performance behavior is not new to Microsoft Dynamics AX 2009; it occurs because conflicts on the primary work center are resolved before moving on the secondary work centers. In cases where the primary work center is scheduled with infinite capacity and the secondary work center is scheduled with finite capacity, the logic goes through additional code loops, and there is a chance that max number of conflicts parameters will be reached quickly. This is especially true when the secondary work center has a large number of conflicts. Note: It is outside the scope of this white paper to discuss the importance of scheduling planned orders only on the basis of bottlenecks. If this feature is used correctly, you should experience improvement in planning results accuracy along with better performance.

Backward capacity time fence

The Backward capacity time fence feature can be better explained with the help of an example. Lets say that todays date is January 2, and a production order that takes 3 days to complete is required on February 2. Logic will first schedule the order back from February 2 to January 2; if no capacity is found, the order will be forward-scheduled from January 2 until capacity is found. Since we know that capacity was not available between January 2 and February 2, forward scheduling from January 2 is a waste of processing time. However, this type of forward scheduling is required because a production order may get scheduled from February 1 to February 3. Based on this example, if the Backward capacity time fence is set to 10 days, then the second pass will search for capacity from January 24 forward.

9 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

First pass backward scheduling from February 2

Second pass forward scheduling from January 2

Capacity scheduled

Current date: January 2

Requirement date February 2 :

Figure 4. Example of capacity scheduling

Additional features
There are a number of additional performance enhancements introduced in the code that do not require any user setup. For example, a feasible scheduling date is now kept in memory, which is effective for items that have a large number of production orders (e.g. due to minimum order size set to a relatively small number). When an item changes direction from backward scheduling to forward scheduling, logic stores the information in memory and first-pass backward scheduling (as shown in Figure 4) is omitted for all subsequent planned production orders.

Addressing customization issues

If you modify Master Planning in Microsoft Dynamics AX 2009, pay special attention to blocking that can occur as a result of the transaction scope encompassing an item dimension. The locks for the records that have been selected for update are not released until an item dimension is completely processed, as shown below.

Select an item

Select a dimension ttsbegin Process transaction for the item dimension ttscommit

Figure 5. Item dimension locking If two concurrent threads are trying to select the same record for update, then one of the threads will have to wait. This results in a significant decrease in parallelism. To help ensure that this situation does not occur, it is recommended that you use generic code.

10 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

You will need to decide how to address this issue using modified code. For example, lets say you have an integer field in the ItemGroup table that gets increased or decreased with the number of requirement transactions that are generated for items falling into that group. This is clearly a problem because concurrent threads may end up updating the same item group record and lead to lock contention. Another type of problem occurs when you have updated a record and need the updated value of this record to be instantly visible to all other threads. If you use the transaction scope used by Master Planning in Microsoft Dynamics AX to update such values, the other threads will not have visibility to the new value until an item dimension is completely processed. To alleviate blocking, you can try the following options: A. Use a user connection to update the record. However, it is important to note that user connections can lead to severe degradation in performance if used frequently. B. Create a delta table that will store the modified value; at the end of the master plan run, use this delta table to summarize the changes. C. Use the ReqProcessItemDimList table with generic code. Although this table has multiple inserts, we have not deployed any blocking or user connection. It is possible to get duplicate values in this table, but they have no adverse effect on master planning because they are inserted into a set before use, thus eliminating duplicates. In addition, you should review the blocking strategy used in the generic code. This is convenient when you need to update a record that is common to all running threads. To view an example, refer to the ReqProcessItemList InsertIfNotExistsOrCheckUpdateLevel code table.

11 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Check whether a record has been inserted

NO

Block a control record (such as reqProcessItemList) using new userconnection setting

Check whether a record has been inserted

NO

YES

YE S

Release the lock on the control record

Create a new user connection: 1) User connection ttsbegin 2) Insert Record 3) User connection ttscommit

return

Figure 6. Sequence of a blocking strategy

12 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Troubleshooting
It is important to note that there is a limit on scaling. As you increase the number of threads and the run time approaches the limit, the scaling should taper off. The parallelism framework is not effective if your single-thread master plan run concludes too quickly (e.g. 1520 minutes). In this case, it is not recommended to use helpers. However, an item distribution factor still should be set; the recommended setting is 100. It is also important to note that all items under a single list are held in memory. Therefore, if you set this value to a large number (e.g. equal to number of items), it may slow the processing time. Furthermore, if you set the value to zero, then each list will have a single item (refer to the formula for calculating list size in the chapter, Understanding the parallelism framework). In this case, the logic will perform a large number of updates on the ReqProcessList record. If your master plan run does not scale, you can perform the following troubleshooting steps: 1. If you are using finite capacity, complete a run using infinite capacity to confirm whether the plan is scaling. 2. 3. Alter the list size. Reduce the number of threads running on a single AOS, and try using an additional AOS. Note: When using an additional AOS, it is important to set the Maximum batch threads (AdminSetup-Server configuration) correctly. Failure to do so will result in running either too many or too few threads on an AOS. 4. 5. 6. Check blocking at the database level. If you are using finite capacity, then blocking on the ProdParameters record is expected. Review the Master planning/inquiries/processes/unfinished scheduling processes form. If you have customized the code, ensure that the ReqCalcScheduleItemTable.Run() method is not inside a transaction scope. For example, the following sample code will result in blocking: ttsbegin; ReqCalcScheduleItemTable.Run(); ttscommit;

13 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

7.

Review the item process time by selecting the Track item process duration checkbox in the Master scheduling dialog box.

Figure 7. View item process duration in Master scheduling dialog box The trace records are stored in the reqProcessItemTrace record and provide details on how much time each item is taking per phase. You will have to export these records to a spreadsheet to perform the analysis. Remember to sort the records on ProcessId, ThreadId, Sort fields to get an accurate picture. By using this trace information, you can: Find out how many items were processed by individual helpers. This should reveal whether there is a hardware bottleneck. Determine which items are taking the longest time, and investigate whether you need to change the item setup (such as revising the maximum order quantity). Find out the time stamp of the last item processed per helper. For example, if all helpers finished processing coverage level zero at 1:00 A.M., but one finished processing coverage level zero at 2:00 A.M., then you need to reduce your list size. Note: Because this table fills up quickly, it is important to delete all records from this table after your analysis is complete.

14 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

8.

Review the Retries executed section of the session Log.

Figure 8. Number of retries executed The value of these fields is expected to be zero under normal circumstances. If either value is not zero, it signifies that you have some code issues. Admin/setup/system/Concurrency Model Configuration has a Log all UPDATE conflict exceptions checkbox. When this checkbox is selected, all statements that caused Optimistic concurrency control (OCC) conflicts are recorded in the Event Log. To determine which part of the code is causing retries as a result of updating conflicts, you can select this checkbox. (You may need to restart AOS).

15 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

Conclusion
With out-of-the-box support for parallelism, Master Planning in Microsoft Dynamics AX 2009 offers greater control and flexibility for scaling. If you encounter difficulties with scaling, there are a number of troubleshooting techniques to try, including switching your master plan run from finite capacity to infinite capacity and using trace records to determine how long items are taking during each phase. For more information about Master Planning in Microsoft Dynamics AX and Supply Chain Management in Microsoft Dynamics AX, visit www.microsoft.com/dynamics/en/us/products/axsupply-chain.aspx.

16 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2010 Microsoft Corporation. All rights reserved. Microsoft, Microsoft Dynamics, the Microsoft Dynamics Logo, SQL Server, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation, FRx Software Corporation, or Microsoft Business Solutions ApS in the United States and/or other.

17 MICROSOFT DYNAMICS AX: MASTER PLANNING PERFORMANCE