Diagnosing performance bottlenecks in your SAP environment when using Winshuttle integration
By Clinton Jones on May 11, 2011
Your BASIS administrators will tell you that your SAP system is idling along with 10% system utilization and plenty of memory and few or no system locks. So why are your users complaining that their batch upload processes are taking so long or that that form is taking too long to respond?
The answer isn’t a simple one. There are many factors that influence overall system response time and the length of time it takes to complete a load. Here are a couple of areas that you should consider with respect to your environment and some areas you may want to discuss with your IT support teams to ensure Winshuttle users have an optimized experience.
First off, you need to get an understanding of how your system has been architected. If the performance problems are pervasive and commonplace then this almost certainly points to an underlying infrastructure problem. However, if the problem is localized or only periodic, then it could relate to the geography of the given user(s) their personal infrastructure (PC, Excel, local office LAN).
If your SAP system has a number of application servers dedicated to either different groups or different functions (like batch processing) then the problem could be there. Consider redirecting your logon to a different server or logon group. Typically this is one of the areas your BASIS and system admins will look at first when you report issues.
With the typical segregation of duties characteristic of larger organizations, you probably have different groups responsible for networks, desktop PC’s and SAP, and accordingly diagnosis of the root cause of a given problem may require participation from all of these groups. Periodic problems may be related to system load or an infrastructure problem, but if you see this happening regularly or cyclically always ask what is going on and engage as many appropriate resources as required. Some performance degradation actually suggests a larger problem could be on the horizon.
Localized issues that are often resolved by a PC reboot suggest that you may have a problem with your local configuration or hardware; issues like aging hard disks, orphaned operating system processes, viruses and driver incompatibilities could suggest that your local machine needs attention. Check and see if your PC is doing a virus scan for example, that often causes performance issues. You can reschedule it for off hours or consider scheduling your Winshuttle job (run later).
A lack of system resources seems to be less of an issue these days with most hardware being relatively cheap and available, but it is worth taking a look at the amount of local resources on your PC and determining if you have a good helping of PC memory and plenty of disk space. If all your applications take a long time to load and the wait cursor transformation (hourglass or spinning circle) is a common experience, then desktop PC attention is definitely the first place to start.
Dial up users will almost always have some kind of latency or performance issues for mass create and mass load batch activities and there is not much that you can do for them. However, remote offices or users who use high speed connections with virtual private networks may need some sort of network optimization undertaken. Concepts like packet shaping and network traffic prioritization are familiar concepts to network admins and can help in improving remote users’ communication with the back end systems. You would do well to ask whether any of these kinds of settings have been established or reviewed.
Beyond the network and your local machine you need to have some understanding of how differently your Winshuttle Transaction or Query products are interacting with your SAP environment as compared with the regular SAP GUI. If the GUI client also performs badly, times out, or is simply non responsive sometimes, then it is likely that Transaction and Query will have similar complaints. If in doubt, always ask your application support or BASIS support group to check on a thing called “SAP dialog response time” to determine if there is something else going on with the user experience that they should look at. Tenured and established IT organizations usually have monitors set up to track key performance and system availability metrics like this, but it is worth asking anyway.
Transaction scripts in particular are highly optimized; however, they are dependent on the underlying configuration of your SAP system and so a process like order entry with VA01 that has many user exits and calls to downstream systems can perform poorly irrespective of the method you are using to create sales orders.
While transaction recordings avoid the delays associated with key strokes, screen refreshes, and the artifacts associated with rendering the GUI experience, they do not avoid the checks and calls made to other areas of SAP and integrated solutions. These checks and calls are after-all what makes your system work and comprise the business logic that helps to ensure that your data goes in the right places in your SAP system and the warnings, errors and messages are appropriate and relevant to the task you are performing. There is no way to know for sure if the performance issues you have are configuration related unless you baseline manual entry against your Winshuttle automation. Things may have changed since you did your original recording and so a cursory review of the system log in Winshuttle is probably worth a look to see if average processing times have degraded.
About the author
The Winshuttle blog is written by professional thought leaders who are dedicated to providing content on a variety of topics, including industry news, best practices, software updates, continued education, tips and techniques, and much more.
Questions or comments about this article?
Tweet @Winshuttle to continue the conversation!