SAP TM Performance – Analyzing the Issue
If you facing a performance issue the first thing you should do is analyzing why it occurs. Is it a rendering issue or a simple performance bug? Is the time spend on client side, server side or on the database?
Only spending money in better hardware might help to hide an issue but in the most cases a simple root cause analysis is much more effective. Therefore, I want to provide a short guide how I start with each analysis. I know there are much better explanations about ABAP performance analysis and thus I will not dig into deep but give an entry point focusing how SAP TM development is analyzing issues.
If you open an incident it helps SAP support/development to provide a pre-analysis of an issue. Nevertheless, in most cases a developer needs to take an own look at an issue. So as usually please provide reproducible examples and an open system connection.
Most of TM applications are WebDynpro applications. That means for each klick some ABAP logic is running on the application server and afterwards the screen needs to get updated on the client. To analyses where the time is spent you can press CTRL+Shift+Alt+P. If you do so a nice little performance tracking tool shows up in the right upper corner of the application. In the tool you can see statistics about the performance of the last round-trip (which is usually the last click you have taken).
The tool can be used to analyses whether time is spent on server side (ABAP code + database) or on the client side (rendering).
Furthermore, you can get an impression how long a click takes for a user better than other traces because for other traces you are usually don’t get the end-to-end time but only the ABAP part. In addition, the tool is not much overhead meaning that it comes close to real user times then e.g. SAT traces.
Most common transaction for ABAP traces I know is the SAT. As I guess there are many blogs/documentations out there explaining the transaction I will just provide a very short overview how to use it.
Normally you want to trace a certain action, like a click in the transportation cockpit. In the WebDynpro application navigate to the action you would like to measure and provide anything in a way that you just need to click (e.g. do the selection upfront…).
Now navigate to transaction SAT in a separate tab. For scheduling a new measurement click on “Schedule” and “New” on the opened screen.
For an WebDynpro trace I usually use “External session” set to “Any”, “Process Type” set to “HTTP” and “Object Type” set to “URL”.
Check that the measurement will be scheduled on the correct application server. If you aren’t sure you can schedule measurements on all servers at ones.
After scheduling the measurement move back to the application session and do your click. When the action takes place, you can delete the scheduled measurement in the list. Be aware that also in case of an UI timeout the action will run through totally. Now move back to the SAT entry screen and switch to the evaluate tab. You should find your measurement here and can open it by double click.
In the measurement, the first thing I usually do is sorting the hit list by net duration to find the easiest performance issues.
Note: An SAT trace will always be slower than the action usually is. The reason behind is that a lot of overhead is created for tracing all the time information.
Long Rendering Time
While the ABAP time is somehow in control of application development for the rendering time there is not much SAP TM development can do. Rendering times hardly depending on the browsers rendering technology as well as the client hardware.
So how to deal with a huge rendering time? First of all, you should upgrade the clients browser to the latest release.
Afterwards you should check whether there is information on the screen which aren’t needed to show. Especially in the transportation cockpit each screen area and each column shown is costing rendering time.
If that doesn’t help you much and it’s fine with your company policy, you can check other browsers. Some browsers can render much faster than others.
For users with very rendering intensive applications like the transportation cockpit it might also make sense to invest in some better hardware as the rendering time is also depending on the clients CPU.
>30% Net Duration Spend in a Single Method
You have taken a trace with most of the net duration spend in a single method? This might indicate a performance bug. Usually the time consuming is spread very wide over the methods. If there is such a massive net duration in a /SCMTMS/ namespace classes, you should search for performance notes in the involved area. Most colleagues add the name of such a slow method to the note for easier search. If you don’t find any notes it might make sense to open a ticket.
Smaller big net duration consumer (starting from 5% duration) might be performance issues too. You should also check for notes for those. But as some logic needs the time without being a bug please don’t send a ticket for every one of those.
But what to do of if Z-code is throwing such issues. Search for common performance issues in the method like retrieve/select in loop or missing usage of keys on internal tables. For easier identifying the issue you can use SAT table traces.
FETCH DB Table /SCMTMS/D_TORXXX
Often a lot of time in traces for entering the cockpit, running the optimizer or running the scheduler is fetching data from the different TOR tables. Sadly, in most cases there is a little we can do with notes. If you forcing such issues, you should check whether you can decrease your data selection and your planning horizon. Selecting less data will spend less time reading those from the database.
More about performance you can find here.
Thanks a lot for this post, we also used to have some challenges regarding performance, but since we upgraded from maxdb to Hana Database our users are a lot more happy. However I still have some questions about the performance of the transportation Cockpit, which is the most used transaction by our users. As you mention each column in the cockpit slows down the performance.
Which columns are displayed depends in the first place on the view the user has chosen, users can create their own views and set them as default when opening the cockpit. However with making views(user or customizing level) which contain less columns we could NOT manage to improve the performance.(Does setting filters in the views and save them as default improve performance? Theoretically less records have to be loaded from the database or does only restricting values in profiles improve performance?)
Not noticing performance improvement we have investigated a SAP recommendation which is mentioned in note 1765952(bullet 4) where it is recommended to create our own Config_ID's. So we copied e.g /SCMTMS/WDCC_PLN_FU_SHP and removed half of the columns and repeated this for each area(FO's, Trucks, TU's etc..) in the cockpit, after this we placed the new config_ID’s in the cockpit and less columns were displayed. The first tests with limited data showed some improvement(8 sec. vs. 10. sec for loading the cockpit) , but with bigger data volumes there was no significant improvement (58. sec. vs. 60 sec). It looks like only little performance improvement was accomplished because less columns had to be rendered in the browser.
Further (superficially) investigation has showed that when we remove fields from the underlying structures there is indeed a performance improvement, but since the cockpit retrieves data from many tables many custom objects have to be made. Since we want to keep as much standard SAP as possible we are doubting if this is the way to go.
My first question is if the above mentioned 'assumptions' are correct, maybe our tests were too superficially and my second question is, is it recommended to create our own structures(if this is required) of course ourselves we have to consider if the custom development is worth the performance improvement, but maybe there are other factors that we should take into account.
Looking forward hearing from you.
With kind regards,
To be honest I’m not an expert in regards of field removing for better performance but if I’m right informed its like this (sadly I’m more an ‘normal ABAP’ expert then an WebDynpro frontend one):
In general, I don’t think that you will catch”the big fish” by those field removings.
When you were talking about predefined filters I was thinking whether there is a way to split up the scenario. If there is a special subset of data the planners are usually need and the filters would be only removed for special cases you might think about splitting to two profiles, one with the subset and one with all the data. Planners would then need to switch the profile when working on the exceptional cases.
It sounds like you are catching a lot of data into your transportation cockpit. Can you provide the following information, maybe I directly have some idea where to sneak into:
Not necessarily needed but something I’m also interested in (if you are willing to share) are some information about the scenario you are running (e.g. shipper planing plant by plant; North America Distribution, all DCs at once…).