Performance of MDG-M central governance is a known problem and has been analyzed and optimized many times with multiple notes and recomendations. Therefore when I was recently asked by customer to look if anything can be still tuned up - especially for big materials with data in multiple (tens) plants - I was a bit skeptical. I thought the improvement I can get would be as usual some 10-20% which eventually will not be noticable by users. However, my findings show it can be improved much, much better.
For very big materials (162 plants) the achieved results are over 3x shorter times of opening existing Change Request (for material with 17 plants the improvement was less spectacular: 7.5 seconds in standard reduced to 5 seconds after improvements, still better than most of the "performance notes" 😉 )
My test case was: open an existing single object CR of type 'Material Change' which was previously saved as draft with a few changes on plant data. The CR type was configured with hierarchical UI and during test just the CR header UIBB and list of Plants UIBB were expanded.
For the material with 162 plants, before optimization the opening time of such CR was nearly 38 seconds, after - it was 12 seconds (and with some additional constraints I achieved even around 5 seconds).
I must mention, that the MM model on which I was testing was extended with a few Z* entities on MARA and MARC level and some Z-fields were added to standard entities - therefore the 38 seconds would be rather shorter with standard model. On the other hand the improvements implemented by me were in standard code (the custom coding was not impacting run times, at least not in my test case).
First thing I did were runtime analysis with tranasaction SAT and checking in the logs what is the weakest point. When you sort the results by number of calls the list shows that the most often called method was run 267k times (!?!?) that's a lot even for very small and fast method, and there are also other methods called more than 100k times:
The next check was to sort the results by gross times, as you know the methods shown in such view are displayed like "matrioshka" - method on top runs the methods below which run the methods below and so on, the goal here is to find a method which does kind of independent task but is still on top of the 'gross time list'. After overview of the metods from top down the CL_MDG_BS_MAT_ASSIST_UI=>GET_COLOR_TOOLTIP_DATA draw my attention - the name suggest it is responsible just for caltulating colors of displayed fields, so it just does this but the time it takes is 29 out of the 37.8 seconds !?!?
For those who are already bored quick hint: switch off HC flag in CR Type configuration and your CRs will open much faster (for big materials):
If you have it already off and your users don't complain about missing higlighting of changes - you can also skip reading here 😉
OK, lets debug and analyze what the method "Get Color Tooltip Data" does - it is relatively short.
Inside there are collected entities of currently expanded UIBBs and at the end the list is passed to service provider method CL_MDG_BS_MAT_SP_SETTINGS=>ON_ACTION_GET_ENTY_FIELD_CHNG to calculate which fields have been changed (including delta between staging and active areas and the changes which were not saved yet) - all the time consuming calculations happen there and it is crucial how many ENTITIES we pass to the method.
Interesting is the logic how the entities from the expanded UIBBs are collected. First the code cheks if there is something set in the field below:
If something is there then it takes just this entity, if the "Entity Type" is empty then istead of reding the values from the entities list ("Entity Types" list visible at the bottom ov the the dialog box above) it collects all entities in a scope under the configured node (MARA, MARC, MBEW, MARD, etc.) which seem to be unnecessarily too many (it should be enough to just collect entities configured in both "Entity Type" and "Entity Types" above - as only these are used to configure the fields on the screen). Anyway the logic above is for form UIBBs and as on forms we process just one record it is still not critical. For list UIBBs it is forced in the code to pass the whole node - and here is the main problem:
As mentioned in the comment above the whole node is passed (node with empty entity pair) to calculate the "Change Icon", even though for calculation of changed fields on the table UIBB it would be enought to pass just configured UIBB entity(ies).
For Plants list the MARC node contains 27 entities (including the Z* ones I have), while UIBB configuration is based usually on a single entity MARCBASIC which has in standard 10 fields (in my case with Z-fields it is 13) - as you know MARC table has hundreds of fields (not all are in MDG-MM model but still there are hundreds). Below rough estimation of number of fields to compare for just MARCBASIC entity and MARC node entities (here still missing MARC Z-entities).
On a list UIBB to higlight changes the application runs fields comparison for all records in the list, then instead of 162x13 it must do 20 times more comparisons (just to calculate the "Changes" icon). I did not analyze deeply the method CL_MDG_BS_MAT_SP_SETTINGS=>ON_ACTION_GET_ENTY_FIELD_CHNG and the code down inside but it looks it was written in a generic way with many layers below, therefore it is relatively slow.
At the beginning of the method you can nottice that it is skipped if the HC flag is not set on current step of CR.
As you know there is standard user parameter MDG_HC_DISABLE with which each user can switch off the higlighting of changes, but no... it does not work this way (SAP, why?). To skip the method and increase performance we need to do it in CR step configuration (with transport and permanently for all users).
For comparison the runtime analysis results with HC off look like below:
You can notice that now the most often run method was executed "just" 57k times (instead of 267k) and the runtime is less than 11 seconds.
The UI output looks now like below: without colors but still with the "Change Icons" which are now named "Staging":
Technically, there are two columns for the icons in the table control and their visibility is toggled together with the HC flag. I've spent some time analyzing what is the difference between them and it looks their purpose is the same - in both cases they are ON if you change some data on any entity of given node (MARC in the case above) and both are set even if the changes are not saved yet. The difference is that the "Staging" icon is calculated much faster than "Changes" icon.
With relatively simple enhancements it is possible to combine higlighting of fields changes and displaying the staging icon (instead of "Changes" icon) and still have a good performance (in my case 12 seconds), but more on that another time...
For very big materials (162 plants) the achieved results are over 3x shorter times of opening existing Change Request (for material with 17 plants the improvement was less spectacular: 7.5 seconds in standard reduced to 5 seconds after improvements, still better than most of the "performance notes" 😉 )
My test case was: open an existing single object CR of type 'Material Change' which was previously saved as draft with a few changes on plant data. The CR type was configured with hierarchical UI and during test just the CR header UIBB and list of Plants UIBB were expanded.
For the material with 162 plants, before optimization the opening time of such CR was nearly 38 seconds, after - it was 12 seconds (and with some additional constraints I achieved even around 5 seconds).
I must mention, that the MM model on which I was testing was extended with a few Z* entities on MARA and MARC level and some Z-fields were added to standard entities - therefore the 38 seconds would be rather shorter with standard model. On the other hand the improvements implemented by me were in standard code (the custom coding was not impacting run times, at least not in my test case).
First thing I did were runtime analysis with tranasaction SAT and checking in the logs what is the weakest point. When you sort the results by number of calls the list shows that the most often called method was run 267k times (!?!?) that's a lot even for very small and fast method, and there are also other methods called more than 100k times:
The next check was to sort the results by gross times, as you know the methods shown in such view are displayed like "matrioshka" - method on top runs the methods below which run the methods below and so on, the goal here is to find a method which does kind of independent task but is still on top of the 'gross time list'. After overview of the metods from top down the CL_MDG_BS_MAT_ASSIST_UI=>GET_COLOR_TOOLTIP_DATA draw my attention - the name suggest it is responsible just for caltulating colors of displayed fields, so it just does this but the time it takes is 29 out of the 37.8 seconds !?!?
For those who are already bored quick hint: switch off HC flag in CR Type configuration and your CRs will open much faster (for big materials):
If you have it already off and your users don't complain about missing higlighting of changes - you can also skip reading here 😉
OK, lets debug and analyze what the method "Get Color Tooltip Data" does - it is relatively short.
Inside there are collected entities of currently expanded UIBBs and at the end the list is passed to service provider method CL_MDG_BS_MAT_SP_SETTINGS=>ON_ACTION_GET_ENTY_FIELD_CHNG to calculate which fields have been changed (including delta between staging and active areas and the changes which were not saved yet) - all the time consuming calculations happen there and it is crucial how many ENTITIES we pass to the method.
Interesting is the logic how the entities from the expanded UIBBs are collected. First the code cheks if there is something set in the field below:
If something is there then it takes just this entity, if the "Entity Type" is empty then istead of reding the values from the entities list ("Entity Types" list visible at the bottom ov the the dialog box above) it collects all entities in a scope under the configured node (MARA, MARC, MBEW, MARD, etc.) which seem to be unnecessarily too many (it should be enough to just collect entities configured in both "Entity Type" and "Entity Types" above - as only these are used to configure the fields on the screen). Anyway the logic above is for form UIBBs and as on forms we process just one record it is still not critical. For list UIBBs it is forced in the code to pass the whole node - and here is the main problem:
As mentioned in the comment above the whole node is passed (node with empty entity pair) to calculate the "Change Icon", even though for calculation of changed fields on the table UIBB it would be enought to pass just configured UIBB entity(ies).
For Plants list the MARC node contains 27 entities (including the Z* ones I have), while UIBB configuration is based usually on a single entity MARCBASIC which has in standard 10 fields (in my case with Z-fields it is 13) - as you know MARC table has hundreds of fields (not all are in MDG-MM model but still there are hundreds). Below rough estimation of number of fields to compare for just MARCBASIC entity and MARC node entities (here still missing MARC Z-entities).
On a list UIBB to higlight changes the application runs fields comparison for all records in the list, then instead of 162x13 it must do 20 times more comparisons (just to calculate the "Changes" icon). I did not analyze deeply the method CL_MDG_BS_MAT_SP_SETTINGS=>ON_ACTION_GET_ENTY_FIELD_CHNG and the code down inside but it looks it was written in a generic way with many layers below, therefore it is relatively slow.
At the beginning of the method you can nottice that it is skipped if the HC flag is not set on current step of CR.
As you know there is standard user parameter MDG_HC_DISABLE with which each user can switch off the higlighting of changes, but no... it does not work this way (SAP, why?). To skip the method and increase performance we need to do it in CR step configuration (with transport and permanently for all users).
For comparison the runtime analysis results with HC off look like below:
You can notice that now the most often run method was executed "just" 57k times (instead of 267k) and the runtime is less than 11 seconds.
The UI output looks now like below: without colors but still with the "Change Icons" which are now named "Staging":
Technically, there are two columns for the icons in the table control and their visibility is toggled together with the HC flag. I've spent some time analyzing what is the difference between them and it looks their purpose is the same - in both cases they are ON if you change some data on any entity of given node (MARC in the case above) and both are set even if the changes are not saved yet. The difference is that the "Staging" icon is calculated much faster than "Changes" icon.
With relatively simple enhancements it is possible to combine higlighting of fields changes and displaying the staging icon (instead of "Changes" icon) and still have a good performance (in my case 12 seconds), but more on that another time...
- SAP Managed Tags:
2 Comments
