High Roll (in+wait) time & GUI time

[Former Member]

Dear Basis Experts,

I have one question about response time and hope to get your guidance.

I observed in STAD and found there was a transaction (PA61) with all kinds of time as below,

CPU time 242 ms

RFC+CPIC time 0 ms

Total time in workprocs 285 ms

=====

Response time 8,880 ms

=====

Wait for work process 2 ms

Processing time 270 ms

Load time 0 ms

Generating time 0 ms

Roll (in+wait) time 8,597 ms

Database request time 11 ms

Enqueue time 0 ms

Roll time Out 1 ms

In 4 ms

Wait 8,593 ms

Frontend No.roundtrips 6

GUI time 8,593 ms

Net time 169 ms

Roll Wait time and GUI time are the same and Net Time is not much high. What reason causes the poor performance?

[Former Member · Accepted solution]

Hello,

As the FE net time is not high and there is low processing time, I also doubt it's a network performance issue. However, you can test this from front-end to app server using niping (see SAP Note 500235).

I would recommend performing an ST05 trace for the user when the problems are being experienced (SQL and RFC trace). You can then search for the GUI flush calls: OLE_FLUSH_CALL. If these are high, a front-end trace may be required. See Note 851012 'SAPGUI: Performance trace - technical details' for further info.

Hope this helps...

[former_member189546]

Hello,

What os are you on?

What is your kernel patch level?

regards,

John Feely

[Former Member]

Dear John,

My HR system runs on AIX with Patch Number (129) of SAP kernel 640 . I will plan to update to the latest version this weekend.

And then try to verify if it will be improved a little.

[Former Member]

Please check in ST02 to see how memory is being utilized.

May be Roll in buffer over utilizied and the work process is waiting for some space in roll in buffer.

Also, check work process trace and you will find why it is waiting for such long time.

Thanks!

[Former Member]

Dear rkandy,

Indeed, I checked the Action of some work processes in Roll-in status in SM50 when system had poor performance. But I also checked in ST02 and found the allocation of 'Roll area' is 400 MB in Memory and 650MB on Disk. But Max. usage of Roll area is just about 28MB. How to explain the situation?

[TomCenens]

Dear

It can be an indication that you have a communication problem between your SAP system and the external system or GUI.

You should check or have the network team check the connection between your SAP system and frontend. You could perform some tests yourself using transaction ST06 --> Detailed Analysis --> LAN Check by Ping --> Presentation Server

There select a number of frontend's and perform 10x Ping (this will use default package size, you can alter the package size through one of the top menu's, note that if you make the package size too large, your firewall might block it and it will result in 100% loss).

In a properly working network you shouldn't have any or very little loss % of your packages and your Max (ms) should not be higher than 20 ms for a local network.

To give you an idea here it is min ms 3, avg ms 5, max ms 9 loss % 0. if you are hosting for a customer it might be slightly higher depending on your server location, the network line between your server location and your customer.

Kind regards

Tom

[Former Member]

Dear Tom,

Actually it's not root cuases about poor FE network, No matter where we connect to SAP via WAN an LAN when system got performance issue, the response of the whole system is slow including like SAPGUI, Telnet, etc,

At that time, I found there are many roll in activities in SM50. But I think the Roll Area is sufficient and why to happen?

[TomCenens]

Hello

Can you please perform the test I recommended to check ?

If you check ST03 do you see SESSION_MANAGER in top used transactions ?

If anything in the test result is out of the ordinary (ms too high, or %loss) you have an indication that it's related to network or perhaps a hardware / software issue of the actual server.

Take block size of 4096 bytes if possible

Edit block size: go to menu path>edit>block size-->4096 Bytes

There are surely differences in ms between WAN and LAN but if you say telnet connection is also slow, it's even more an indication that you might have connection issues.

The following SAP Notes for your reference:

-SAP Note Number 161053 - Low Speed Connection is in use

-SAP Note Number 164102 - Network load between application servers+camera front end

-SAP Note Number 62418 - Network Load of SAPGUI Frontend Communication

It's either, a network performance problem, a connected system problem (GUI or external system) or is there a lot of data is being loaded (file uploaded from frontend to application server).

Do the users perhaps have huge user menu's or is there use of large image files (custom images in transaction to display logo of company or something similar). Such things could also give more roll wait time.

Kind regards

Tom

[Former Member]

Dear Tom,

I still believe it doesn't network performance issue. Because I have another ERP system in the same network segment with the poor performance system (HR). When the HR system has performance issues, it took me a lot of time to connect to the HR system. But it's so good to connect to my ERP system at the same time. In my case of some response time, it might be poor PC with SAPGUI?

[TomCenens]

Dear

You should first determine if this is a general issue or not.

Check the values of ST03 (parts of response time tab) for today for example and check how many % is roll/wait time

Kind regards

Tom

[Former Member]

Dear Tom,

It usually takes place the poor performance during the mass data of running report. It impacts the whole system performance.

But I observed the memory usage of the report tooks about 3GB EM memory and i also have 6GB of phiscal EM. Therefore, why will the execution of one report be such serious? Almost there are many WPs in Roll-in activities.

[TomCenens]

Dear

Please read the following thread:

[;

The first answer to this thead is the answer to your question, the checks he proposes are valid for your case and can give you more insight on where the issue lies.

Kind regards

Tom