RFC as a program in STAD

[Former Member]

Hi,

We have performance problems with a background job which runs for a very long time.

so as to access the performance we have run STAD for the user which has triggered the job, in the result I could see lot of entries with RFC as a program and they have huge response time.

server Program Response Time in Wait time CPU time DB req. VMC elapsed Memory Transfered

-

---

-

---

-

---

-

---

-

---

-

---

-

---

--- -

---

-

---

<server1> RFC <user> 386.546 386.522 12 201.27 89.867 0 57.432 141.881,3

<server2> RFC <user> 321.654 321.54 49 151.36 103.746 0 53.373 157.956,3

where server1 is our central instance, server2 is our dialog instance.

I did not understand what exactly does this RFC mean? and why it is taking so huge response time.

Kindly help

Regards,

Brahmeshwar

[mercedes_fernandez · Accepted solution]

Hello Brahmeshwar,

SAP Note 552845: FAQ: RFC Statistics in Transactions ST03/ST03N and STAD provides information for these statistics records.

kind regards,

Mercedes

[Former Member · Accepted solution]

Hi Mercedes.

Thanks for the note.

But what I did not understand is when I am running the job in a single system why RFC calls are coming into picture.

Pls clarify me.

Regards,

Brahmeshwar

[mercedes_fernandez · Accepted solution]

Hello Brahmeshwar,

does the program running in job RFC calls?

Keep in mind as well that if the Enqueue runs in the central intance the reads operations from the application server to the

enqueue table are done via RFC.

kind regards,

Mercedes

[Former Member · Accepted solution]

Mercedes,

Sorry for the late response. I was retrying, analysis my problem and now I understood a little about these RFC program in stad.

We are actually using parallel processing using RFC logon group for our program and I assume this is the reason why RFC program is being displayed in stad, besides the rfc communication for enqueue.

But, the response times for these entries are too high... Is there any way by which we can optimize this?

Regards,

Brahmeshwar

[Former Member · Accepted solution]

Hi,

If you use parallel processing it means that most of the processing is done by RFC calls. So it is perfectly normal to have high RFC response times.

Why do you consider the response times to be too high ?

Regards,

Olivier

[Former Member · Accepted solution]

Olivier,

Thanks for the response.

I am using parallel processing for the first time and I am not aware of RFC calls taking high response times.

I ran through stad and I could see response times upto 624,000 , 568,456 ms response times for RFC calls.

I was not sure if these response times are normal.

Thanks,

Brahmeshwar

[Former Member · Accepted solution]

Poloju,

The response time depends from what is done inside the RFC call.

But usually, if you have to use parallel processing it is because the data processing is intensive.

You can run an SQL trace and see what is done.

If you get 624 s for 2 SQL requests to read 2 table lines it is very bad.

If you get 624 s for 2000 000 SQL requests to read 100 000 000 table lines it is very good !

Do you get the point ?

Regards,

Olivier

[Former Member]

Hi Brahmeshwar,

You may also want to drill down further into the single RFC records themselves. The large response times might not be for single calls but for a large number of calls.

If you select the RFC records in the single statistical record, you'll (by default) see only the top 5 but you'll also see how many RFCs were generated in this record. If the top 5 don't look particularly long in terms of calling time (total time for RFC call) and execution time (time to actually do the work), it may be that it's down to the large number of calls. In this case, as already mentioned, parallelisation will help.

If the top calls are expensive, then you need to trace for the reason why i.e. trace the job in ST12 or ST05 whilst running. Or better still, just filter for the expensive function modules.

Cheers,

Tony