Question on performance parameters [Archive]

Eddy G

18th June 2003, 10:06

General

Display Time Interval - For Simulate Orders (cprrp1210m00). It is the minimum time between two refreshes of the progress bar. Except for value 0, there is hardly any performance gain. When you make it 0, the progress bar will display the active item (can be usefull when Simulate Orders seems to hang, and you want to know for which item this is the case). Note that value 0 will have a negative influence on performance, as it will refresh the progress bar very often (mostly even faster than you can read).

Unlimited Commits - This in fact is a left-over of Triton and Baan IV functionality. The concept is outdated and hardly used. Just fill in value 0.

Multiplier 2-D Calendar Arrays - This is a rather technical parameter that has to do with the allocation of internal memory for loading the calendars during for instance Simulate Orders and Simulate Master Plan. Filling a small value will save memory use, but filling a value that is too small will cause abortion of sessions. The value that you have to fill in is related to your calendar definition: how many calendar lines do you have per day. If you for instance define only 1 line per day (9:00 till 5:00), then value (1 or) 2 will do, if you define an average of 4 lines per day, then value (4 or) 5 will do. So, as a rule of thumb: take the average number of calendar lines per day, and add 1 (or 2) to this value. Note that any calendar that is being used by these sessions has to fit. Therefore you have to concentrate on the most detailed calendar.

Parallel Processing
All parameters below have only to do with running Simulate Orders with parallel processing.
Average number of Planned Orders per Item
This one has to do with the following: During parallel processing several processes will be started that each of them will perform the planning of a set of items. Each process will receive a predefined range of planned order numbers that it can use to generate planned orders (without interfering with other processes). The value here defines the given range. When the value is chosen too high, then you will see (huge) gaps in the order numbering; when it is too low, the processes don't have enough numbers reserved for themselves and will start fighting each other for order numbers. This will cause considerable performance loss.

The three parameters below are interrelated and have to do with the following: Suppose you have a lot of easy-to-plan items (for instance Purchased Items), and some difficult-to-plan items (for instance Manufactured Items with thousends of materials or hundreds of operations). Then you can have the following situation: Suppose you have two parallel processes and 10 items (5 difficult; 5 simple). If you now give the 5 difficult items to the server 1 and the 5 simple items to server 2, then you are not performance-optimal, for server 2 will finish in no time, and then everyone has to wait for sever 1 to finish. With the below parameters you can influence the balancing (but it is rather specified).

The first determining parameter is: Dynamic Workload Calculation (check box). It also determines the meaning of the other parameters.

Dynamic Workload Calculation = NO
Workload per Server = the number of items that are handed over to a process, as a group.
Suppose the value is 10. In that case the items will be devided in groups of 10 items and these groups will be divided over the servers.
Choosing a small value will cause more client-server communication, choosing a high number will save on client-server communication but might cause waiting time (example: Suppose you have 300 items, and Workload = 100. Then 3 groups will be made. If you now have 2 servers, each server will get a group. The first one who is finished will get the last group. But now the other process has nothing to do any more.)
Workload based on Operations (check box) - not in use for this situation.

Dynamic Workload Calculation = YES
Workload based on Operations = NO
This situation is almost equal to the one above. Only the distribution of the groups of items will be done a little bit smarter.
Dynamic Workload Calculation = YES
Workload based on Operations = YES
In this case an estimate of the weight (easy or difficult to plan) of the item will be made by counting the number of operations of the item. The weight will be the number of operations (but at least 1).
In this case the Workload per Server = the weight that you want to have in a group