High roll time for HTTP in ST03

[Former Member]

Hi All,

I have an issue in PI System where I could see very high roll wait time.

Can anyone please help me out to reduce the roll wait for HTTP requests.

Thank You

Regards,

Satyardha

[alwina_enns]

Hello Satyardha,

is the roll wait time unrealistic high? Which kernel release and hernel patch level has the affected system? A few weeks ago this fix was release for the 7.21 kernel:

2241334 - ST: Queue time too big

and for the 7.42 and 7.45 kernel releases:

2246730 - TH, ST: Queue time too long for GUI communication.

You may need to apply at least the kernel patch mentioned in the SAP notes above.

Regards, Alwina

[Former Member]

Hi Enns,

Thank you for your reply.

HTTP roll wait time is high in specific time regularly. When I checked for jobs running in that specific time, I found one HR related job running in ECC system and this is processed to Success factor via PI runs. Is anything need to be checked in Adapter Engine/Integrated?

Current version kernel 720 and support package level 700.

Can anyone please suggest how can I troubleshoot this issue and fix for that.

Please advise.

Regards,
Satyardha

[Former Member]

Hi,

As I mentioned above, there was a job from ECC might be responsible? but if it is not the reason, how can I go and check in PI System regarding the system. What actually would be the cause for the issue.

Please advise.

Thank You.

Regards,

Satyardha

[alwina_enns]

Hello Satyardha,

could you please provide a screenshot from ST03 about this high roll wait time?

You can check with the F1 help documentation for the roll wait time. As described in the documentation this time is not included in the response time for the RFC task type and it can be high, if for example the client is waiting for an answer from the server. In ST03 in the transaction profile you should see for which report or transaction this high roll wait time is reported.

Why do you think this is an issue? Do the user complain about bad performance?

Regards, Alwina

[Former Member]

Hi Enns,

Actually we have an issue with high response time where we are getting an alert regulary in specific time. Client has asked to sort out this alert issue.

We have a tool when the dialog response time exceeds 5000ms , we will get an alert.

But when I checked for dialog tasks, I couldnt see any dialog steps being carried out at the time of alert generation. So I felt the reason for this could be RFC and HTTP requests high roll wait resulting the high dialog response time. But I am not sure what actually the reason could be.

But as you specified I could see with F1, this doesn't count under response time.

I have attached the screenshots of response time, transaction profile and also the background jobs taking high response time. Please refer below screenshots.

Does the background job counts in dialog response time? When I checked for the alert time and background job run, they are almost at same time. Moreover, we have a job that runs employee data from ECC via PI runs, that also in that specific time.

Does these jobs resulting the dialog response time more that 5000ms? Can you please advise on this. It has been long time, I was checking this.

[Former Member]

Hi,

Can anyone please help me on this for above and also please let me know whether background job response time count in dialog response time?

Please advise.

Thank You.

[Former Member]

Hi All,

Can anyone please suggest me on this.

Thanks in Advance

[alwina_enns]

Hello Satyarda,

if you are getting the alert only at a certain time, please check the time profile in ST03 for the affected time period. If you double click on the line in this time profile you will see transaction and reports executed in this time frame.

In the workload overview you can check with F1 help the "Task Types", which steps are displayed under which task type.

You have mentioned first the high response time for the HTTP, later you are talking about the dialog task type. This is not the same.

What you see in the alert which you are getting - for which task type it is created?

Regards, Alwina

[Former Member]

Hi Alwina,

We have an alert for dialog response. I have a doubt here, whether background/http/rfc response time/db time/cpu time, does this involve the increase in dialog response time. I was thinking this way because, we have an alert tool set for dialog response time. But i couldnt see any dialog in that specific time but still we have high dialog response time, So I was thinking this might be because of RFC/HTTP/BTC jobs.

Can you please clear me on this.If I check for dialog tasktype in that specific time ,I couldnt see. But we are getting an alert for the same. So Is there any task type that resulting high dialog response time other than dialog task type?

please advise

Regards,
Satyardha

[alwina_enns]

Hello Satyardha,

in the dialog task type only steps from the dialog users are recorded. In the documentation in ST03 for the dialog task type you see - "Transaction step usually started online by the user". A batch job can be responsible for the too high response time in dialog if it starts too many RFCs and and these RFCs occupy the Dia WPs, so that the dialog users do not have free WPs to work. In this case in the dialog task type the wait time will be high.

How the alert is created? Which threshold values are set to create the alert? What is the data source for the alert? What collects data for the dialog response time? Probably you should check also, if the alert is justified and created correctly.

Regards, Alwina

[Former Member]

Hi Alwina,

I have a btc job EU_REORG responsible for updating indexes. It has high response time daily and also DB response time is also more. Does any chance this may impact the dialog response time?

If you have any idea about this job how it functions? please let me know.

Thank You

[alwina_enns]

Hello Satyardha,

no, I do not know, what the job EU_REORG is executing and if it buids RFCs and if it requires the Dia WPs. It would be a good idea to check the traces of the affected instance at around the time, when the alert is created, if any bottlenecks are reported.

Regards, Alwina