Checklist for improving MRP performance – Part 1: How to run MRP

If Master Planning (MRP) runtime is too long, here are a couple of simple things you can try in order to improve it. The list was compiled for Microsoft Dynamics Ax 2012, so parts of the checklist may not apply to earlier versions. You must, of course, try these out on a test environment first and, if you see an improvement, apply the same settings to the production environment. It is recommended that you apply one setting at a time, so you can get a good sense of what helped and what didn't. It is also recommended that the test environment is as close as possible to the production environment in terms of data volumes: number of products and number of transactions. If you are running MRP in recurrent batch, note that some of the settings will be cached, so it's better to make the parameter change and re-create the batch and then run MRP again.


1. Use helpers for master planning

Using helpers (parallel processing threads) during master planning will most likely improve the runtime. Request one or more helper threads when running master planning, by setting the Scheduling helpers - Number of helpers parameter in the Master scheduling dialog to a value greater than zero.

More information about helpers can be found here:



Also make sure you have applied to the Ax environment the latest hot fixes related to helpers. Below are just a couple of KBs that you should consider installing or porting to your AX version:

KB article 2693422

KB article 2690230

KB article 2862912


2. Number of helpers used during master planning needs to be less than or equal to the maximum number of threads allowed on the batch server

It makes no sense to have the number of threads requested by planning greater than the sum of available batch threads on all batch servers in the selected batch group that runs master planning. Set the number of master planning helpers to be lower than the sum of available batch threads on all batch servers in the selected batch group to run master planning or increase the number of threads on selected batch servers.

To check the number of available batch threads per server/batch group go to System administration - System - Server configuration


3. Use multiple AOSs for master planning

Using more AOSs during master planning will most likely improve the planning runtime. It is also very important that you make sure no other lengthy routine is running simulataneosuly with master planning. It is also very important that you make sure no other routine requireing locks on tables used by master planning (for example InventTrans, InventSumLogTTS, ReqItemTable, etc) is running at the same time as MRP. 


4. Configuration keys that are not actively used should be disabled

For example, when Process Industries functionality is used, a lot of additional planning logic is being triggered, like for instance expiration dates for batches. This will increase the master planning runtime. If Process Industries functionality is not used, make sure the 'Process manufacturing' configuration key is switched off.


5. Action message usage

Calculating action messages leads to longer master planning runtime. If action messages are not analyzed and applied on a regular basis (daily, weekly, etc), consider disabling the calculation during the master plan run, by making sure the Action message time fence is 0 on the master plan you are running (Master planning - Setup - Plans - Master plans). Also make sure all the coverage groups have Action message setting disabled.


6. Futures usage

Calculating futures leads to longer master planning runtime. If you are not planning BOMs or if propagating delays from supply to demand during planning is not needed for you, consider disabling futures calculation during MRP, by making sure the Futures time fence is 0 on the master plan you are running. Also make sure all the coverage groups have Futures setting disabled.


7. Number of tasks in a master planning helper task bundle

Changing the number of tasks in the task bundle may have a positive effect on the runtime. The number of tasks in a bundle controls how many items are planned together by a single helper. It is recommended to increase the number of tasks when the number of items is very large (hundreds of thousands) and decrease the number  of tasks otherwise. In most cases it is a trial and error approach before an optimal value is determined. Remember to change this value as you add to Dynamics Ax more and more products!


8. Caching during master planning should be set to Maximum

Master planning logic is controlling the amount of caching used. This parameter is obsolete and is a candidate for removal in future versions of Microsoft Dynamics AX. In all the companies master planning is executed, consider setting Master planning parameters -  Use of cache to Maximum

Comments (4)
  1. Fredrik Sætre says:

    Also there is a feature for Production planning optimization in The AX that is set to time out after 2 seconds as default. If you set The parameter to 0 you might gain some efficiency if you have a lot of transactions. The parameter is found on Org. Mngmt. og System Setup under Setup and planning.

  2. Very good point! The parameters you are reffering to are under Organization administration – Setup – Scheduling – Scheduling parameters.

    If users are doing production scheduling during MRP, then they can consider doing the following to decrease MRP runtime:

    1. disable scheduling optimization by making sure Scheduling optimization timeout enabled is unchecked

    2. if optimization is needed for production scheduling during MRP, consider decreasing the time the scheduling engine should look for a better solution, by filling in a smaller value in Optimization attemps timeout field (note that the value is in seconds)

    1. Deepak says:

      I tried disabling scheduling optimization and this really worked for me. Thanks for your suggestion.

  3. Thomas Sicard says:

    Section 7, is there a calculation rule that can be used before starting the "trial and error approach" ?

    Let's take an example. If we have, 440k items and want to execute your MRP with 20 threads, what could be the initial value ? 440k / 20 ?

Comments are closed.

Skip to main content