High roll wait Time

[Former Member]

Dear all,

We are experiencing some high times in ST03, specially in Roll Wait Time and GUI Time which are over 400 ms.

In previous threads we have found that probably it was a problem of network.

Using ping command

Reply from X: bytes=32 time=51ms TTL=122

Reply from X: bytes=32 time=51ms TTL=122

Reply from X: bytes=32 time=55ms TTL=122

Reply from X: bytes=32 time=52ms TTL=122

Ping statistics for X: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),s

Approximate round trip times in milli-seconds: Minimum = 51ms, Maximum = 55ms, Average = 52ms

Could you kindly provide us any workaround to solve this issue?

Has anyone know if there is any good practice to apply in this kind of situations?

Thanks in advance for your collaboration.

Best regards,

Maite

[Former Member · Accepted solution]

n previous threads we have found that probably it was a problem of network

Then why you ask this question on performance forum if you know the problem (in your network) ? You need to ask your network admins why your network are not configured correctly. Regards.

[Former Member · Accepted solution]

Dear all,

Thanks for your quickly and helpful responses.

It is not clear it was a problem of the network. It's just what it has been said in previous threads in this section.

First we need to check if there is a performance issue. At this point we have check swaps buffer (ST02), CPU and memory utilization (ST06)

By using ping command it seems that no problem on network was found. Using Lan check by ping (ST06) pings commands are executed in a short time, so no problem was found at this point.

Could you kindly recommend me something more to check?

Thanks a lot,

BR,

Maite

[Former Member · Accepted solution]

We are experiencing some high times in ST03, specially in Roll Wait Time and GUI Time which are over 400 ms.

This indicates you have problem on frontend PC's(GUI problems) or in network between your SAP APPL server and the frontend PC's , in same st06 -->detail --> lan check by ping --> press on presentation server and check pings to workstation's (especially with higth load in ST03n roll wait and GUI).

P.S. -->

Reply from X: bytes=32 time=51ms TTL=122 are you think the 51ms are good network?? -->

It's ping from my server my PC -->

Reply from X: bytes=32 time=<1ms TTL=122

Regards.

[Former Member]

Hi Maria,

As per your last comment, are you concluding the users in your Local Network, the roll wait time is fine, and the users access from outside network it is high. If so, probably you have the answer. In general you should expect high roll wait if you are accessing over the internet. As long as roll wait in your LAN is good, you are OK. The Network team can investigate if they can minimize the wait time over the network.

Regards,

Sanujit

[Former Member]

Dear all,

Case is still open, I will provide you some more information just in case it will be helpful for anyone.

After executing report EASY_ACCESS_NUMBER_OF_NODES, all users have less than 100 entries which is desirable. Only 9 user have more than 100 entries but they have no more of 600 entries.

BR,

Maite

[Former Member]

Can you explain what you want to hear? Post information about time distribution for user who is in your LAN but have

high  roll wait Time + Gui time

are at least 1 user ? Or all users from not in your local network?

[Former Member]

High Roll Wait does not always indicate for a problem in the system.In case you have cleared off all areas that would potentially impact a roll wait pls refer to the following SAP Note:-

-

---

Note 1073521 - Response time without GUI time II

-

---

In case an end user downloads data into a front-end control Ex: MS Excel and doesnu2019t close it for about ten minutes, this ten minutes too is computed in Dialog Response time, which is incorrect.

When to close the front-end control < i.e. MS- Excel / MS Word > is purely end user discretion and has nothing to do with a systemu2019s performance in reality. But the KPI roll wait time is misleading in this case.

Also to clear off the network area, pls use NIPING tool rather than PING tool as the former uses TCP/IP protocol which is the same used by SAP application and later uses ICMP protocol. For details refer to:

-

---

Note 500235 - Network Diagnosis with NIPING

-

---

cheers !

PRADi

[Former Member]

Dear all,

After checking with niping network response time we have conclude that there is no connection between the high roll wait time and network issue.

We have strongly recommend to change the execution of some transactions from dialog to background.

And finally response time has decreased.

Thanks all for all your contributions.

Best regards,

[Former Member]

Dear Maria,

Kindly contact your network administrator for network issue and check you have sufficient number of dialog work process. As explained earlier because of in sufficient number of dialog process this issue could come.

Kindly let me know ,Do you face this issue at particular instant of time (when load on the system is high) or All the time .If you face issue all the time ,kindly increase number of dialog work processes .

Thanks and Regards ,

Arun Kumar

[Former Member]

Hello Maria,

You monitor your network response from the front-end to the SAP system, you can run niping on a couple of workstations. You can run it for a day for example and check the output if you find high throughput times in your network.

Kind regards,

Mark Dijsselbloem

[Former Member]

Dear all,

The times are from a different network of the server, for this reason we assume that there is no problem at network. While doing ping at the same network the results obtained are:

Min (ms) Avg (ms) Max (ms)

8 8 8

The ping command at SO command show the following results

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Reply from X: bytes=4096 time<1ms TTL=128

Ping statistics for X: Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

So this parameters does not show network major problems

In the other hand the number of WP are the following: DIA 10 y BTC 3.

Thanks all for your collaborations!

BR,

Maite

[Former Member]

Are you ping the frontend host (where high roll wait time and gui time) from your app server ?

Can you check in st03n --> detailed analys --> last minutes load .. try to find the users with high Roll and gui, after ping his presentation servers for exampl in st06.

P.S.10 and 3 are small for productive, but you need check the main memory on server to increase this numbers ...

Regards.

[Former Member]

The roll wait time is most of the time part of RFC communication. Perform in ST05 an RFC trace and share the results.

Kind regards,

Mark

[Former Member]

Dear Sergo,

You are right that the number of wp is not significant. In this sense CPU utilization is not reporting problems, Idle CPU oscillates between 80-90% and the system is not paging. The system has a stabie use CPU is more or less regular between the values said before and also for use of memory,...

Furthermore in system log there are no problems reported or malfunction of WP.

Times in ST03 for CPU, DB, process time ... does not represent problems at all.

BR,

Maite

[Former Member]

And you check the last load and ping presentation servers?

Or you find other problem?

[Former Member]

Dear Sergo,

We have checked the load minute and we have identified the user. We have ping from server to this presentation servers and the time obtained for min, avg and max time is 28 ms.

Is it recommended to be a bit lower?

Thanks for all your recommendation.

BR,

Maite

[Former Member]

If it's your local network the 28 ms is very high.

[Former Member]

Dear Sergo,

In parallel to this forum, I have checked performance object and no errors where detected. So I 've asked my colleagues from network team to check and send me more detailed information.

Thanks all for you helpful responses.

KR,

Maite

[rakesh_ranjan]

Hi,

In case of high GUI and Roll Wait time, you should also check response time of transaction SESSION_MANAGER in ST03. If response time of transaction SESSION_MANAGER is high combined with high GUI time, definitely it is a problem with front-ends and it also indicate that the SAP Easy Access menu might not be configured correctly and should be tuned to improve overall response times.

It is also possible that your users have been assigned disproportionately large user menus. We advise you to ensure there are a reasonable number of entries (nodes) in the User Menu. Refer to SAP Notes 203617 and 203994.

Generally, it is recommended that users should have no more than 1000 and as an absolute maximum 2000 menu nodes configured, (for comparison, the complete SAP menu contains 70,000 entries). A high number of entries may lead to high memory consumption on the server and to long response times for the menu.

You can check user menu nodes by running the report EASY_ACCESS_NUMBER_OF_NODES (earlier u201Cprofgen_corr_report_5u201D).

Also, check if front end users have deactivate the new visual design to reduce the CPU consumption on their desktop PC. In case of slow network or user connecting through WAN they should deactive the new visual dedign. With this new architectural design of Enjoy elements the roundtrips to the GUI are considerably increased and the processing between the application and the presentation layer seems to be sequential. Refer to SAP Note 203924 Enable the Low Speed Connection that reduces the quantity of data transferred per dialog step and other measures.

for LAN Check by Ping, standdard response times are:

- In a local area network (LAN) : <20 milliseconds

- In a "fast" Wide Area Network (WAN) (for example, 256 or 384 KBit/sec): < 50 milliseconds

- In a "slow" wide area network (WAN) (for example, 128 KBit/sec or less): < 250 milliseconds

- Losses of data packets ("Loss") should not occur at all.

If result of your Ping is more than described above, then this indicates problem with network.

Also, refer to below Notes.

161053: Low Speed Connection is in use

164102: Network load between application servers +camera front end

62418: Network Load of SAPGUI frontend Communication

Hope this will help you further investigating the problem.

regards,

Rakesh

[Former Member]

Dear all,

From a network point of view there is neither errors nor discarded packets. We only see that linkStateChange is a little high but nothing more that points to a trouble.

SESSION_MANAGER is not the transaction which shows the highest response time but it is on the fifth position.

As I have observed with ping commands there is no problems with users in the same network but if there is someone accesssing from another network then it shows reponse time in average higher.

So the question is: Should we investigate further at network level to identify why linkStateChange is so high or Could we conclude there is a problem with the GUI frontend?

Thanks a lot for your responses.

BR,

Maite

[Former Member]

Hi,

Roll wait time is a combination of roll-out, roll-in and wait time in

one value. The reasons why a process may incur delays here are varied

and numerous.

An RFC or Remote Function Call is a call to another system or process to

execute a routine in another environment. This can be either

Asynchronous (whereby the originating task continues in parallel (often

used to speed up overall execution by using multiple processes), or

synchronous, (most often executed in a remote system), in which case the

originating task waits on the completion of the RFC routine. In the case

where it is synchronous you will most likely see the originating task

rolled out and incurring roll-waittime.

So i hope that you might be calling RFC at time when your Roll wait time is higher.

Wait time can and frequently is because there are insufficient dialog

processes for a txn to start so the delay is in waiting for a free

process to become available, that however is only one of many reasons

why you may see rollwaittime.

It is also a measure of time in which a txn is suspended during

operation. When this occurs the txn is effectively paged (or rolled) out

of memory to save resources.

Hope this will help you , revert in case of any clarification.

Regards,

Gagan Deep Kaushal