Roll Wait time is high (RFC wait)

[Former Member]

Hello Performance Experts,

We have one external SAP add-on installed in the system.

We use some xxxx transactions to access the functionality of this Add-On Application in SAP.

But the performance is very very poor for this application. When I have checked with the Vendor of this Add-On, they have told that the same addon is running without any performance problems in other customer landscapes.

The addon provider tells us that it might be the problem with Buffer settings. But when I checked the buffer just few hundred swaps are there in the whole system and the buffer quality for all paraleters are more than 98%.

When I checked the ST03N and STAD transactions, I could see that Average response time is more that 25000 ms for any transaction related to this application.

Then I could see that 90% of the time is just "Roll Time --> Wait"  (Roll wait time).

Task Type: RFC

RFC Interface time is always more than 120,000 ms and sometimes it is 350,000 ms.

Can anyone please let me know is there any configuration problem or how to solve this issue?

I have attached the relevant ST03N screenshots for the reference.

Thank you in advance.

Regards,

Eswaran

[Former Member]

Hello,

Please find the update:

SAP has recommended to implement this SAP note: 2241957.

I have implemented this sap note but as of now no change in the response time.

Is there any further recommendations from you guys?

Regards,

Eswaran

[Reagan]

Quick question: Assuming that the issue is on the production system, how did these transactions do in the test environment?

I would consider tracing these transactions and see what it says.

[Former Member]

Hello Reagan,

the same problem can be reproduced in Quality system as well.

But not in Development system. So I could not debug the same.

Regards,

Karthick Eswaran

[ImtiazKaredia]

Hi,

Go to the section RFC in STAD. There should be some details like below.

Click on the number shown for the calls. This will give breakup of what exact program or function is taking time. This should help you or Paste those screens for us further support.

Thanks

Imtiaz

[Former Member]

Hi Karthick,

Roll wait time high could also mean shortage of dialog work process. As in your case one dialog work process is making RFC call and is waitiing for another dialog work process to pick it up and come back with required data.

Also, check if the max runtime value for dialog wp is not set to a higher value.

Roll wait time ideally it should be 10% of the average response time.

Regards

Prithviraj

[Former Member]

Hello,

please find the attached screenshot of the RFC Detail:

Kindly suggest some ideas to solve this problem.

[Former Member]

Hello Prithviraj,

how do you know in my case only one dialog process is used.?

Because we have enough Dialog processes configured in our server.

Most of the time above 20 dialog workprocesses per instance is always available.

1, Is there anyway we can configure to increase the number of dialog processes for this particular application?

2. as of SAP Basis 740 Max Runtime for Dialog work processes are automatically set as per sap default and I did not modify the same.

Below are the parameters for max quota set for normal and low priority dialog processes.

rdisp/scheduler/prio_normal/max_quota 70%

rdisp/scheduler/prio_low/max_quota  70%

Regards,

Eswaran

[Former Member]

Hello Performance Experts,

I could always see that the Function Module name is always the below when I get the performance problem and the wait time is high.

QDEST_RUN and QDEST_RUN_DESTINATION

Please suggest or share your viewes to solve this problem.

Thank you,

Eswaran

[ImtiazKaredia]

Check SMQS/SMQR and check scheduler status when you run these transaction.

Check Note 1485789 - QRFC: Long running processes in SM50

1885482 - Timeout dumps: delete internal table all_state in QDEST_RUN

[isaias_freitas]

Hello,

QDEST_RUN is a function used by the Outbound qRFC/tRFC Scheduler.

I do not see how this would be related to the initial scenario being described.

Do this addon/transactions create RFC entries (transactions SM58 or SMQ1)?

If not, then this STAD record is not related to your scenario in any way .

Regards,

Isaías

[Former Member]

Hello Isaias,

I could not see any SMQ1 entries, but there are entries in SM58 with the same user.

Rgds,

Eswaran