When you are using RFC load distribution via the SAP logon mechanism, no load distribution occurs. This causes the potential capacity overload of individual application servers or logon groups.
The load distribution mechanism of the Remote Function Call (RFC) which among other things is available as an option for R/3 destinations, only uses logon groups for load distribution. Here, the load distribution information is only refreshed via participating servers of a group by the message server after about 5 minutes (profile parameter rdisp/autoabaptime, default value 300 seconds). Thus the required load distribution is not achieved for an application during massive parallel processing. This mechanism must not be used for such applications.
Related: Create and Maintain RFC Destinations
For this, a RFC-internal load distribution procedure together with the asynchronous RFC is available (check online documentation on asynchronous RFC).
The transactional RFC has a corresponding parallelization brake as of database Release 3.0F to avoid an overload situation.
Applications that want to execute parallelization on a large-scale via the asynchronous RFC, that is with ABAP key word CALL FUNCTION func STARTING NEW TASK taskname and so on, but not via the transactional RFC, that is with ABAP key word CALL FUNCTION func IN BACKGROUND TASK and so on must use RFC groups for the load distribution in the same system. For this see the online help on asynchronous RFC.
If an overload situation exists when using the transactional RFC in an R/3 configuration, then the following steps must be executed:
The application executes tuning measures in order to reduce the system load. This can be carried out in cooperation with the Early Watch department.
The system configuration must be adjusted optimally for the installed applications. Here, you must examine whether the number of R/3 instances need to be increased. Here, the Early Watch group can be of help also.