- SAP Managed Tags:
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.
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.
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.
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.
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.
Tools
CTRL+Shift+Alt+P
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.
SAT
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.
Issue Solving
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
More about performance you can find here.
3 Comments
| User | Count |
|---|---|
| 5 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
