Moving forward, I will be aggregating the KBA statistics for General Performance by the Quarter, thanks to everyone for the kind comments and suggestions. I'm glad that we are making an impact with troubleshooting.
The champion Knowledge-Base Article, this is the single most important and popular document that send to all of our customers. If you don't already know about ST12 traces, you better start because it will change the way your troubleshoot some of your toughest problems. This KBA will take you step by step on how to take an ST12 trace and how to analyze it so that you can pinpoint where your problem may lie. There is a reason why this KBA continues to take the throne and that’s simply because it’s the grand tool to solve your problems.
I can't stress the usefulness of KBA, please, do yourself a favour and jump on the ST12 bandwagon. Make sure you have this tool in your arsenal. Now, let's move on.
If ST12 did take #1, this tool would sure take the crown. /SDF/MON is simple a tool that keeps a record of SM50 and ST06 snapshots. Again with this tool, if you aren't already using it, start today, it will save us time and most importantly, yours.
Use this tool if you are having performance problems through the day and not all the time. Use this tool if there is a job at night and you want to see how the system reacts in according to the job. Use this tool if you want to see if you have any work process shortage. It’s a great tool to get an overview of the system at all times of the day.
This tool does not add any extreme overhead unless certain parameter is set such as CPU per session
Now you know, on to #3
Again, moving up to third place this quarter is a Knowledge-Based Article completely written about OLE_FLUSH_CALL. I’m sure you have all seen this line before when you are analyzing ST12 traces. Let us help you understand why this shows up and what the next step you can do to find out if this is normal or the delay is caused by front-end programs. Here is a quick summary of what the KBA will cover:
A few points that are covered in this KBA are:
-Determining if the runtime is the problem
-The number of times OLE_FLUSH_CALL is called
-Network Infrastructure and Traces
-SAPGUI Version management
-Performance GUI Traces
Add this KBA to your list of staple KBAs, it may help you in the near future.
Onto #4..
Another favourite of SAP employees and our customers is this KBA dedicated to the troubleshooting of High GUI time seen throughout STAD and ST03n monitors. It continues to gain traction as one of the most popular KBA because of how often problems like this happen.
It walks you through a single transaction or programs in STAD which can also be found in the Workload Monitor. There are many scenarios that you may see high GUI time including:
-Large volume of data transfer from the application server to presentation servers (frontend GUI).
-Low network transfer rate between application server to presentation servers (frontend GUI).
-Long time on executing/interpreting the RFC calls on presentation servers (frontend GUI).
-The display time on the frontend is long due to the performance of frontend PC is considerable bad.
Fix your GUI problems so that you can work on more important task.
Dropping down to 5, we have a KBA all about High RFC Time which was also in our previous TOP TEN KBA’s. To give you a quick summary of what you’ll find in this KBA, we will show you how to interpret the high RFC times seen through STAD and ST03/ST03n. This may be one of the most difficult topics in General Performance as high RFC time can be caused by many, many variables. Some may be:
Network performance issues
The result of communication and high data volume issues
Slow running jobs between different SAP systems (for example ERP and BW)
Indicated by high roll wait time in the ST03 monitor.
In this scenario, a job that is running between SAP systems can take a long time to complete the target system, which can be an application, hardware or database specific issue.
Unavailable RFC resources
Individual RFC resources are overutilized on the target system which can generate high wait time.
A misreported response time which is not related to an actual performance issue, but rather a bug related in manner.
In this case, the response time will be unrealistically high.
High RFC time is provided in Early watch alert.
An Early watch alert will highlight RFC response time as yellow if it exceeds the monthly average threshold of 2400ms and red if it exceeds the average threshold of 3600ms.
I must admit, RFC is by far one of the most vague KPI's but this is a great start!
We are seeing this article becoming much more popular, which is good! Here we have the “Survival Guide for performance analysis on SAP Systems”, the bible for general performance problems. Refer to this guide whenever you are looking for information on General performance and this includes cross-platform integration problems.
What is Cross-Platform Integration Problems? A great example I like to use is a CRM UI user trying to access a list of the employees but the loading is far too slow. The goal of this guide is to assist you in finding if the problem lies in the frontend, network, application layer, or the database layer and more.
This documentation covers:
-System initial analysis
-Key performance analysis transactions
-Workload analysis
-Network performance analysis
-Database related performance analysis
-Useful performance analysis tools
-SAP service process
A simple yet cumbersome problem, this KBA will go over the performance issues seen from RFC processing a large amount of entries in ARFC tables. There is a report that can be run to clean up the table which is described more in the KBA. Glad to see this article being used!
Make sure you have this in the back of your toolset.
Whether you have problems in parallel RFC processing of an external RFC destination in SM58 or the connection test of External RFC deestination in SM59 with high response time, this KBA will assist you with all that The error message you may see will look like this:
Error Details ERROR: timeout during allocate of registered program
Error Details LOCATION: SAP-Gateway on host Hostname/ sapgw00
Error Details DETAIL: TP Test_Program init/busy for more than 60 se
This happens due to the poor network performance between RFC client and external RFC server, or the external program which registered on the SAP gateway
is currently being used by other process,RFC client which calling the external RFC destination cannot access the registered gateway program until the registered
program was released for accessing.
Otherwise,the accessing to external program failed with error””timeout during allocate” when exceed the gateway timeout(parameter gw/reg_timeout).
If you have this problem, get to fixing with this KBA.
We get questions. Many questions. Most of the time we already have an answer for it but we still have a load of problems that go over our head. We compiled a list of all the questions that are asked. Some of the questions that you'll find in this list are:
Do you already see a question that has your interest? What are you waiting for? Go through this KBA, you won't be disappointed.
Last but not least, this article covers what to do if you suspect latency issues between your application servers and your database. Did you know that the recommended response time between your application servers and database server is anything under 0.7 milliseconds? Anything above is considered a poor performing network.
Take notes everyone, this is also a really important KBA to know!
If you made it this far! Thank you from the bottom of our hearts, we continue to create meaningful KBA that help/fix your problems, whether that be network or ABAP server, we are here to help!
Yours Truly,
Danny Tran
2436955 - Step by step instructions on how to use ST12 trace for analysis
752 Views
The champion Knowledge-Base Article, this is the single most important and popular document that send to all of our customers. If you don't already know about ST12 traces, you better start because it will change the way your troubleshoot some of your toughest problems. This KBA will take you step by step on how to take an ST12 trace and how to analyze it so that you can pinpoint where your problem may lie. There is a reason why this KBA continues to take the throne and that’s simply because it’s the grand tool to solve your problems.
I can't stress the usefulness of KBA, please, do yourself a favour and jump on the ST12 bandwagon. Make sure you have this tool in your arsenal. Now, let's move on.
2383809 - How to configure /SDF/MON for performance monitoring and analysis
629 Views
If ST12 did take #1, this tool would sure take the crown. /SDF/MON is simple a tool that keeps a record of SM50 and ST06 snapshots. Again with this tool, if you aren't already using it, start today, it will save us time and most importantly, yours.
Use this tool if you are having performance problems through the day and not all the time. Use this tool if there is a job at night and you want to see how the system reacts in according to the job. Use this tool if you want to see if you have any work process shortage. It’s a great tool to get an overview of the system at all times of the day.
This tool does not add any extreme overhead unless certain parameter is set such as CPU per session
Now you know, on to #3
2457530 - Performance problems with OLE_FLUSH_CALL, how to analyse
481 Views
Again, moving up to third place this quarter is a Knowledge-Based Article completely written about OLE_FLUSH_CALL. I’m sure you have all seen this line before when you are analyzing ST12 traces. Let us help you understand why this shows up and what the next step you can do to find out if this is normal or the delay is caused by front-end programs. Here is a quick summary of what the KBA will cover:
A few points that are covered in this KBA are:
-Determining if the runtime is the problem
-The number of times OLE_FLUSH_CALL is called
-Network Infrastructure and Traces
-SAPGUI Version management
-Performance GUI Traces
Add this KBA to your list of staple KBAs, it may help you in the near future.
Onto #4..
2428353 - How to analyze high GUI time on SAP systems
459 Views
Another favourite of SAP employees and our customers is this KBA dedicated to the troubleshooting of High GUI time seen throughout STAD and ST03n monitors. It continues to gain traction as one of the most popular KBA because of how often problems like this happen.
It walks you through a single transaction or programs in STAD which can also be found in the Workload Monitor. There are many scenarios that you may see high GUI time including:
-Large volume of data transfer from the application server to presentation servers (frontend GUI).
-Low network transfer rate between application server to presentation servers (frontend GUI).
-Long time on executing/interpreting the RFC calls on presentation servers (frontend GUI).
-The display time on the frontend is long due to the performance of frontend PC is considerable bad.
Fix your GUI problems so that you can work on more important task.
2418936 - High RFC time: Performance troubleshooting
452 Views
Dropping down to 5, we have a KBA all about High RFC Time which was also in our previous TOP TEN KBA’s. To give you a quick summary of what you’ll find in this KBA, we will show you how to interpret the high RFC times seen through STAD and ST03/ST03n. This may be one of the most difficult topics in General Performance as high RFC time can be caused by many, many variables. Some may be:
Network performance issues
The result of communication and high data volume issues
Slow running jobs between different SAP systems (for example ERP and BW)
Indicated by high roll wait time in the ST03 monitor.
In this scenario, a job that is running between SAP systems can take a long time to complete the target system, which can be an application, hardware or database specific issue.
Unavailable RFC resources
Individual RFC resources are overutilized on the target system which can generate high wait time.
A misreported response time which is not related to an actual performance issue, but rather a bug related in manner.
In this case, the response time will be unrealistically high.
High RFC time is provided in Early watch alert.
An Early watch alert will highlight RFC response time as yellow if it exceeds the monthly average threshold of 2400ms and red if it exceeds the average threshold of 3600ms.
I must admit, RFC is by far one of the most vague KPI's but this is a great start!
2442365 - Survival Guide for performance analysis on SAP system
219 Views
We are seeing this article becoming much more popular, which is good! Here we have the “Survival Guide for performance analysis on SAP Systems”, the bible for general performance problems. Refer to this guide whenever you are looking for information on General performance and this includes cross-platform integration problems.
What is Cross-Platform Integration Problems? A great example I like to use is a CRM UI user trying to access a list of the employees but the loading is far too slow. The goal of this guide is to assist you in finding if the problem lies in the frontend, network, application layer, or the database layer and more.
This documentation covers:
-System initial analysis
-Key performance analysis transactions
-Workload analysis
-Network performance analysis
-Database related performance analysis
-Useful performance analysis tools
-SAP service process
2548815 - Performance issue with RFC processing with a large amount of entries in ARFC Table
183 Views
A simple yet cumbersome problem, this KBA will go over the performance issues seen from RFC processing a large amount of entries in ARFC tables. There is a report that can be run to clean up the table which is described more in the KBA. Glad to see this article being used!
Make sure you have this in the back of your toolset.
2426336 Performance analysis of external RFC server programs (registered program)
145 Views
Whether you have problems in parallel RFC processing of an external RFC destination in SM58 or the connection test of External RFC deestination in SM59 with high response time, this KBA will assist you with all that The error message you may see will look like this:
Error Details ERROR: timeout during allocate of registered program
Error Details LOCATION: SAP-Gateway on host Hostname/ sapgw00
Error Details DETAIL: TP Test_Program init/busy for more than 60 se
This happens due to the poor network performance between RFC client and external RFC server, or the external program which registered on the SAP gateway
is currently being used by other process,RFC client which calling the external RFC destination cannot access the registered gateway program until the registered
program was released for accessing.
Otherwise,the accessing to external program failed with error””timeout during allocate” when exceed the gateway timeout(parameter gw/reg_timeout).
If you have this problem, get to fixing with this KBA.
2399769 - General Performance: Troubleshooting Questions
132 Views
We get questions. Many questions. Most of the time we already have an answer for it but we still have a load of problems that go over our head. We compiled a list of all the questions that are asked. Some of the questions that you'll find in this list are:
- Is the Performance issue sporadic/random or does it occur at a fixed time?
- Have you recently implemented any changes to your system landscape?
- Is this isolated to a single server?
- Have you recently had an EarlyWatch service? If so, have the recommendations been actioned?
- Do you have load balancing or logon groups configured?
- Has there been a recent increase in system users?
- Does this concern a single user, or multiple users?
Do you already see a question that has your interest? What are you waiting for? Go through this KBA, you won't be disappointed.
2543171 - Latency issue between application server and Database
110 Views
Last but not least, this article covers what to do if you suspect latency issues between your application servers and your database. Did you know that the recommended response time between your application servers and database server is anything under 0.7 milliseconds? Anything above is considered a poor performing network.
Take notes everyone, this is also a really important KBA to know!
If you made it this far! Thank you from the bottom of our hearts, we continue to create meaningful KBA that help/fix your problems, whether that be network or ABAP server, we are here to help!
Yours Truly,
Danny Tran
- SAP Managed Tags: