(1) What is an RFC statistic record?
(2) What WP processes a RFC?
(3) I can't see tasktype 'R' in SM50.
(4) Client and server subrecords
(5) Response time, CPU time, Wait time
(6) What is 'Calling time' and 'Remote Execution time'?
(7) 'Calling time' and 'RFC+CPIC time'
(8) Response time, 'RFC+CPIC time' etc.
(9) Occupation of WP
(10) CPU time = 0 but Response time > 0
(11) When is a RFC stat record written?
(12) WP occupation during RFC
(13) Client and server records (1)
(14) Client and server records (2)
(15) Performance problems
(16) Calling time and remote execution time
(17) Response time of RFC server is larger than calling time
1. Q: What is an RFC statistic record? Some records in transaction STAT/STAD show 'RFC' as a program name. All these records contains either 'Client subrecords' or 'Server subrecords'. These records are of task type 'R', but such task type doesn't exist according to the documentation.
A: For every dialog step (or batch step) where remote function calls occur a separate RFC statistic record is created. In this record all outgoing and all incoming RFC calls are collected (outgoing calls are client sub records and incoming are server sub records). The instance profile parameter stat/rfcrec gives the maximum number of individual RFC sub-records shown. The program name RFC is artificial. You can't map one single report to this statistic record because every RFC call could be located in a different program. In the RFC stat record details, you can see the individually called function modules and their report names. The task type R is also artificial as RFC calls could be made from any other task type.
2. Q: What WP processes a RFC? When we perform RFC calls to a remote system, what tasktype is assign to process the call on the remote system?
A: The RFC call is always processed by a dialog work process on the receiver (= server) side if the receiver is a R/3 system. But, as explained above, the R/3 statistic record will be of task type 'RFC'. In case of an external receiver system it will be processed within the external process context. Additional information: In case of IDOC transfers the inbound processing of the IDOC on the receiver side can be separated (depending on the customizing setup of the message type on the receiver side). For the update processing of received IDOCs it depends on the inbound function module whether an update record will be created or if it will directly update in the dialog work process (set update task local).
3. Q: I can't see tasktype 'R' in SM50. If it is task type 'R', I can't see it in system monitoring, why? (Transaction SM50).
A: The RFC calls are shown in SM50 as 'stopped CPIC' on the sender side. On the receiver side you'll see the report name of the function module which is processed in a dialog task (in case of asynchronous or transaction RFCs you'll see SAPLARFC or SAPLERFC as report names - in case of synchronous RFCs you'll see the report name of the called function group).
4. Q: What are 'Client subrecords' and 'Server subrecords'?
A: Client subrecords are written on the client side. Each client or server subrecord contains information about a single RFC call and includes the name of the function module and the remote target. The parameter stat/rfcrec limits the number of RFC subrecords per statistic record. If more RFC calls are performed only the most expensive records (with the highes execution times) are kept. The client destination and subrecords contain the summary information of all calls to a particular destination. The server destination records contain the summary information of all incoming calls of a particular destination. The number of destination subrecords is also limited by the parameter stat/rfcrec and only the most expensive destination records are kept.
5. Q: What is meaning of Response time, Wait time and CPU usage for RFC records?
A: Response time is the sum of response times of all collected RFC calls for the related dialog step. The single RFC response time is the total time from when the call was started until the result is returned (in case of a synchronous RFC - for asynchronous RFC the response time ends as soon as the receiver confirms reception of the data). The CPU and DB times are collected for all locally used CPU and DB times of the RFC calls. The Wait time is the time until a free dialog work process could be allocated to process the call (in case of incoming calls or asynchronous RFCs). The remote CPU, DB and Wait times are not known by the sender and therefore you might see a significant gap between response time and the sum of the others (for synchronous RFC).
6. Q: What is 'Calling time' and 'Remote Execution time'?
A: RFC Client: the calling time is measured in the gateway. It is the total time from the start of the RFC call on the client side until the result is returned (in the synchronous case or until the data is shipped in the asynchronous case). The execution time is the processing time on the RFC server and is transferred to the client. RFC Server: the calling time is measured in the gateway on the server. It is the total time from the start of the RFC call on the server side until the result is returned (in the synchronous case or until the data is shipped in the asynchronous case). The execution time is the processing time on the RFC server.
7. Q: Why the 'Calling time' is always equal to 'RFC+CPIC' time for 'Client records'?
A: The RFC+CPIC time can be found in the 'time details' of the single statistic records. The RFC+CPIC time is often equal to the 'calling time' of the RCF client records because they are identical except the time in the gateway.
8. Q: What is the relation between Calling time (Rem.Exec.Time) and CPU time, RFC+CPIC time, Response time, Roll wait time?
A: Response time = sum(Calling times)
Calling time = Rem exec time + wait for gateway time
RFC+CPIC time = time spent for RFC/CPIC handling (incl. Roll wait time)
Roll wait time = time spent in roll context waiting for RFCs
CPU time = sum(CPU usage) (on the server where the record is found)
Calling time (Client)= Rem exec time + (wait for) gateway time + network time
Calling time (Server)= Rem exec time + (wait for) gateway time
Response time = Time spent in the executing workprocess + Wait time
9. Q: I would expect as critical for system performance that we don't occupy all dialogs. Where can I see how long was the dialog occupied by my transactions?
A: You can use transaction SM50 to monitor the WP activity. Transaction SM51 can be used to monitor the dispatcher wait queue. There You can see the number of waiting requests in the dispatcher queue. The field "wait time" of the statistic records shows the time in the dispatcher queue for each request. The field "Time in WP" shows how long a work process was occupied by this request. The difference between the response time and the time in the WP is usually the time when the context has been rolled out due to RFC or GUI communication. Use the parameters rfc/use_quotas and rfc/min_wait_dia_wp to reduce the risk of all dialog WP used by concurrent tRFC send calls or a RFC calls for a RFC server group (see note 74141 for details).
10. Q: For some RFC statistical records is the CPU time = 0, but the Response time is > 0. Why?
A: The CPU time consumption of the RFC server is not recorded on the client side. Therefore the response time may be large although the CPU time consumption is small on the client side. Anyway, it could also indicate a problem with time measurements on multiprocessor systems.
11. Q: When is a new Statistical record created in system monitoring? Is there just one new record for each dialog step?
A: There is one record per dialog/batch step. For RFC calls You get additional subrecords:
client: up to stat/rfcrec client records for the most expensive single calls; up to stat/rfcrec client destination records for the most expensive destinations (summary information).
server: up to stat/rfcrec server records for the most expensive single calls; up to stat/rfcrec server destination records for the most expensive destinations (summary information).
The RFC statistic records are written when a roll out occurs.
12. Q: Is the the DIALOG workprocess occupied also during RFC call? Or is it available for another task during waiting time for RFC call results?
A: This depends on the type of RFC. During a synchronous RFC the calling DIA WP has to wait (SM50: stopped CPIC) until the results are returned. It will not consume CPU but is not available for other DIA requests. For asynchronous RFC calls the sending DIA WP is free as soon as all function input data is transmitted and this transmission is committed by the receiver. The asynchronous RFC (aRFC) cannot return any results. For transactional RFCs (tRFC) it is a little more complicated. The handling of tRFC depends on the current system load. If there are sufficient resources available (depends on profile parameter and current system load) it is handled like a asynchronous RFC, otherwise like a synchronous RFC.
13. Q: When I look at the 'RFC' records (type 'R') in the system statistics I see that some 'Client subrecords' don't have corresponding 'Server subrecords' and vice versa. What does it mean?
A: Client records are written on the RFC client for outgoing RFCs. Server records are written on the RFC server for incoming RFCs.
14. Q: Why in some RFC records (statistical records) has certain 'Client subrecord' also corresponding 'Server subrecord' (in the same RFC record!), but in some other stat. RFC records, 'Client subrecord' and 'Server subrecord' are located in different statistic records.
A: Client records are written on the RFC client for outgoing RFCs. Server records are written on the RFC server for incoming RFCs. It could happen that a task is client and server simultaneously. In this case, You will see client and server records.
15. Q: Is there any danger on gateway side when we are shooting so many RFC calls?
A: Yes. There are several resources used by the gateway which are controlled by instance parameters for the gateway. See notes about this.
16. Q: When looking on 'Calling time' and 'Rem.exec.time', Does it make sense to sum these values for Server and Client records? If yes, what Client's and Server's records should be summed and how?
A: As you can only see the most expensive calls (limited by the parameter 'stat/rfcrec') it usually makes no sense. Rather look at Client destination subrecord and Server destination sub records which does the summary for you.
17. Q: The 'Calling time' and 'Rem.exec.time' of an RFC server record are shorter than the response time. The difference is about 500 ms.
A: After the RFC request has been processed the work process (WP) waits for the next call. It will stay in the receive mode for 500 ms. If no additional call is performed the context is rolled out and the stat records are written. By calling the function SYSTEM_RESET_RFC_SERVER or SYSTEM_RESET_RFC_CONNECTION from the client the RFC server process may be terminated immediately without waiting 500 ms for an additional RFC.