When creating large allocation cycles, it's always good to know the limitations for segments in the allocation configuration. If the configuration is not optimized,
you might have severe runtime problems with cycles of assessment, distribution, periodic reposting or indirect activity allocation in CO-OM.
According to note 79224, various reasons that may cause performance problems in an allocation scenario are :
1. You exceeded the cycles dimensions recommended by SAP. (a maximum of 50 segments per cycle, a maximum total of 10,000 sender-receiver relationships).
2. The entered allocation characteristics are unfavourable for the selection in the database. First, all allocation characteristics of all segments of a cycle are 'added' (minimum/maximum strategy). With this maximum of selection criteria, the selection is made in the database and the invalid records are sorted out afterwards. For most customers, this procedure greatly improves performance. If all your segments are structured similarly and, for example, differ only in the sender cost element group (for example, assessment apportioned by cost elements into many assessment cost elements), this minimum/maximum strategy is unfavourable.
We have a hard limit of 998 segments per cycle and the field 'Segment Number' has only three digits.
The basic ideology here is that the run time increases exponentially with the number of segments. All segments that are iterative need to be in one cycle. Segments that are not iterative should be defined into one cycle as a sustainable number, presumably 100-200 segments. If there are too many segments in one cycle, not only the run time increases but the complexity of the cycle also suffers. If the result list has 25.000 pages or more, it wouldn't be possible for anyone to understand the same.
Inside one segment the number of sender and receiver is only limited by the memory consumption and runtime. You can define 1 Million items in one segment, the question is what the run time will be required to incorporate the objects. Especially WBS-Elements are quite time consuming as their master data is exceedingly complex. For example, if you have 2 groups, one cost center group having 30 costs centers and one WBS element group with 65 000 WBS elements in the sender and a receiver part with 2 groups: One cost center group with 30 costs centers and one WBS element group with 65 000 WBS elements. this would be resulting in 4.225.000.000 combinations, which might lead to a crash due to memory overflow.
Please check the note
79224 - Allocations: Performance problems solution 1 for further details regarding the same.
In a nutshell, the database performance and selection, along with the expected result list should be taken into consideration before creating a cycle.
