JCo Performance 

Problem Description

A J2EE application which uses either Java Remote Function Call (JRFC) or Java Resource Adapter (JRA) to connect to an SAP system is demonstrating poor performance. The loss of performance could be related to one of these components.

Scenario Type:	Error analysis
NetWeaver Component:	SAP JCo 6.40 (JRFC) and SAP Java Resource Adapter (JRA)
Validity:	JRFC and JRA since Web AS 6.40 SP9

Decision Roadmap

Main Tools

●     Visual Administrator

●     Config Tool

Possible Error Sources

●     Too much data

●     Too many parallel calls

●     Poor backend performance or network problems

●     Bugs or an inadequate programming style

Analysis

If applications respond slowly or even hang and you want to know the reason for the loss of performance, you have to collect data about the CPU, memory or time consumed by different processes. There are different ways of getting this information, ranging from OS commands like top or ps to Java profilers with complex functions. However, the aim of this PAS is to describe how the two monitoring tools JARM (Java Application Response Time Measurement) and CCMS (Computer Center Management System) of the SAP J2EE Application Server can help to retrieve more information about JRFC and JRA performance.

In order to analyze JCo-related performance problems in the J2EE application server context, it is helpful to know how SAP JCo, JRFC and SAP JRA relate to one another. SAP JCo Standalone is the component that you can always use to connect to an SAP system from a Java application. JRFC was developed for J2EE applications in the WebAS. It differs from SAP JCo in the implementation of the lower layers, but has the same API. Finally, if you want to integrate SAP systems compliant to the Java Connector Architecture (JCA), you have to use JRA. JRA again uses internally JRFC for communicating with an SAP system.

The performance reporting tool JARM permanently monitors the data flow for different J2EE components, including JCo. Normally, JARM monitoring is switched on by default for JCo. If this is not the case, start the Config Tool and set the Java parameter –Djco.jarm=1 for the relevant server instance and restart the server instance. Data written by JARM can be viewed using the two services Monitoring and Performance Tracing of a server instance, which you can access with the Visual Administrator. For the Monitoring service, go to Runtime -> Monitor Tree -> Performance -> Application Responsetime. Here you will see information such as the number of calls, average time spent for a call and the amount of data that was sent. This data is displayed from different viewpoints, such as for each request, component or user. If you select view for each request or component, JCo distinguishes between the three components com.sap.mw.jco.JCO.Client, com.sap.mw.jco.JCO.Server and com.sap.mw.jco.JCO.Repository. If you interpret this data, you have to remember that the times for the client include the time spent in the backend. You have a similar situation for the JCo server, where the time could include the time to call an EJB, for example. You can get the same information in the Monitoring service in the Performance Tracing -> Runtime -> JARM service, as shown in the figure below.

 

Component Overview of JARM

 

If JARM is switched on, JCo is also activated for the single activity trace (SAT). In other words, if you select SAT Trigger for the Performance Tracing -> Runtime -> Trace Config service and call an application where JCo is used, the LogViewer -> Runtime -> <server instance> -> sat.trc service also displays trace entries for the JCo components com.sap.mw.jco.JCO.Client, com.sap.mw.jco.JCO.Server and com.sap.mw.jco.JCO:Repository. Below you can see a SAT for JCo client and server activities. The components involved are listed for each activity and ordered according to the criteria “what was called by whom”. You can display detailed information about a component if you click on the respective entry.  

SAT for SAP JCo Requests

The SAP J2EE application server writes Distributed Statistical Records (DSR) for CCMS, which also contain information about JCo activities. When you start a CCMS agent, this information is transferred to a central SAP system and can be displayed and analyzed by CCMS transactions. For example, for Windows platforms you look for the executable sapccmsr.exe in your J2EE application installation, call this executable, then you get a description of how to register a CCMS agent at an SAP system. When you have successfully registered the CCMS agent, you can check in transaction RZ21 of the SAP system under agents of remote systems to see if the CCMS agent was correctly registered. Then change to transaction STATTRACE or ST03G, select your J2EE application server as the system and define a period of time for which you want to display the DSRs. If everything went fine, you see the memory usage and the time needed for each call for the JCo requests.

With the help of DSRs you can also retrieve the time spent in the backend when you call a function module at an SAP system from a J2EE application. In this case, you have to search for the DSR which was written in the same period at the SAP system. Below you see an example. The function module STFC_CONNECTION was called from a servlet. In figure 2 you see the response time for the call which was measured on the J2EE application side, and in figure 3 you see the time the call has lasted in the SAP system.

DSR written on the J2EE application server side (ST03G)

 

DSR written on the SAP system side (ST03G)

If you have analyzed the relevant application in detail and are thinking about how you can increase performance, it is probably a good idea to check if you could improve your application before you upgrade your hardware. The following two examples indicate which programming styles should be avoided for JCo programming. First, if JCo connections are opened in several threads to the same SAP system, do not use an extra repository for the meta data for each thread. Instead, try to share one repository for all threads. You can check how repositories are applied in your application by comparing the number of calls for the component com.sap.mw.jco.JCO.Repository for a single and multiple threaded scenario in JARM. Secondly, if you have to transfer a large amount of data, transfer it not as an internal table or nested structures, but use tables or simple data types instead. If you need further help to improve JCo performance, open an OSS message for the component BC-MID-CON-JCO.