cancel
Showing results for 
Search instead for 
Did you mean: 

JCo performance

Former Member
0 Kudos

I have a Web Dynpro application running on SAP Netweaver Portal 2004s, on top of SAP Web AS 6.40.The Web Dynpro access a R/3 backend, direct through JCo (I'm not using Adaptive RFC). The pool settings of the JCo destination are:

pool size 100

maximum connections 100

connection timeout 10 s

maximum waiting time 2 s

I'm responsible for the performance tuning, under low load (<100 concurrent users) the application behaves as expected. However, with more than 100 concurrent users, the calls to the backend get very slow. Using the Performance Monitor of Visual Administrator, I checked which are the slowest requests. The component that is taking the most time to execute is .JCOClientConnection.resolveConnectionParameter (sometimes it takes up to 70 seconds net time!). The actual calls to the backend, through the com.sap.mw.jco.JCO.Client component are taking less than a second. Is there some way to optimize this .JCOClientConnection.resolveConnectionParameter ?

The portal runs in a machine with 8 Dual Core AMD Opteron(tm) Processor 875, 995.422 Mhz, 1024 KB cache, 32 GB RAM, IBM J2RE 1.4.2, the size of the heap (minimum=maximum) is 2048 MB, using a garbage collection policy optimized for short average pauses. The processor utilization under high load is about 80%-90%.

Thanks in advance

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

I dont think the pool settings that you have made, are optimal.

Go to help.sap...checkout the recommended time-out(in sec). I'l say, increase the connection timeout & max waiting time.

Try going to <i>sap service marketplace</i> & use the QuickSizer tool.

It is a very useful tool, where you enter your system hardware & software configuration, then provide details about the user-activities.

It then gives you an optimum configuration for your system.

Former Member
0 Kudos

Reducing the waiting time was indeed an optimization: under high load, all the connections are used, then the requests for new JCo clients are enqueued. This results in more threads (and the corresponding context information) that must be managed by the processors. With a load of 150 concurrent virtual users, so many requests were enqueued that the processors were saturated. Although at this point the load generator was stopped, the high CPU utilization remained high (due to the enqueued requests with a high waiting time). As a result, the portal freezes, and must be restarted.

Using a smaller waiting time, the requests are not enqueued a large time. Then under high load, the worst problem is that if the waiting time is exceeded, an error ocurrs, but the processor does not get stuck (and the portal does not freeze), and when the load generator is stopped the portal returns to its stable status, without need of restarting.

The JCOClientConnection.resolveConnectionParameter entry in the trace is generated by the method IWDJCOClientConnection getJCOCientConnection(String name) of the class com.sap.tc.webdynpro.services.sal.sl.api.WDSystemLandscape. This class provides access to the interface that describes a JCo destination defined in the J2EE cluster. But this method does not yet get the client (thus the connection timeout and max waiting time do not affect the behavior of this method), the client itself is obtained by the method com.sap.mw.jco.JCO.Client getClient() of a class that implements IWDJCOClientConnection.