Parallel processing - time between each RFC call

[Former Member]

Hi,

I am working in a program using parallel processing and the time between the function module calls are being around 4 seconds.

Example:

WHILE....

MESSAGE 1

CALL FUNCTION 'ZZZZ' STARTING NEW TASK 'task' DESTINATION IN GROUP 'group'

     PERFORMING 'form' ON END OF TASK.

.

.

.

MESSAGE 2

ENDWHILE.

The time between message 1 and message 2 varies in seconds but never less than 3 seconds. The return code of the function call has been always 0 and there is no problem with lack of resources.

I implemented another test program in a different environment and I am calling a dummy function module 15 times in parallel, all of the calls were triggered in the same second.

Someone has experienced something like this?

Thanks,

Felipe

[deependra_shekhawat3]

Hi Felipe,

how and what dummy function you are calling in different environment ? are you using same way to call or you are calling via server group ?

I don't think it matters on seconds, how much work process (Foreground/Background WP) assigned that matters.

Please elaborate more with example.

[Former Member]

Hi Deependra,

For tests purposes I created a function module containing only a 'wait up to 60 seconds' and executed the same way I described in the post, using a server group and a receiver form.

The difference is that in one environment, the one that contains the function module that process real data, the time between each call is around 4 seconds.

In the other environment with a completely different configuration, I created a new program to simulate the parallel processing and check how it would run, and the result is that the function modules are being triggered all at the same second.

Examples:

Environment 1:

WHILE....

     MESSAGE 1 - ( Begin - 13:30:00)

     CALL FUNCTION 'ZPROCESS_REAL_DATA' STARTING NEW TASK 'task' DESTINATION IN      GROUP 'group'

     PERFORMING 'form' ON END OF TASK.

     MESSAGE 2 - ( End - 13:30:34 )

ENDWHILE.

Enviroment 2:

WHILE....

     MESSAGE 1 - ( Begin - 13:30:00)

     CALL FUNCTION 'ZWAIT_UP_TO_60_SEC' STARTING NEW TASK 'task' DESTINATION IN      GROUP 'group'

     PERFORMING 'form' ON END OF TASK.

     MESSAGE 2 - ( End - 13:30:00 )

ENDWHILE.

Do you know what would affect the time of those calls?

Thanks,

Felipe

[deependra_shekhawat3]

Hi Felipe,

Looks like may be due to system and available foreground work process particularly.

I never got this time of scenario or tried multiple parellel processing Function module.

[Sandra_Rossi]

continuing Deependra's answer, here is the link to the pRFC configuration (7.0, a bit old, refer to your version for accurate info) : http://help.sap.com/saphelp_nw70/helpdata/en/6e/3f560a3e0f6f4a90fb1e7db1388d4d/frameset.htm

also make sure how your RFC server group is defined (RZ12). How many servers do you have. Are they all up (SM51) . Etc. Compare everything between the 2 systems. Make sure how many dialog workprocesses you have (SM50); and how many are assigned to aRFC.

[Former Member]

Hi Sandra,

Thanks for your reply.

After I checked the link below and sap note 597583, I did some tests and found out that the time taken between each call depends of the type and number of the parameters which is being passed to the RFC.

Configuration of System Resources for aRFC, tRFC, qRFC - Components of SAP Communication Technology ...

Once I was testing with different RFCs, the time obviously(or not) was different. When I included more parameters in the my test RFC the time between each call increased some more seconds.

Also, in the RFC, when I changed the importing parameters to tables parameters, the performance was increased a little bit.

So, my conclusion is that the time taken between each call is related to the number and type

of the parameters (single values/tables) and if we cannot reduce the number of parameters in the RFC there is nothing we can do to improve the performance on this point.

Obs.: In my tests the number of lines included in the internal tables passed as parameters didn't affect the time between each RFC call.

Regards,

Felipe

[Sandra_Rossi]

It's difficult to understand why a different number of parameters does change the performance. Or your system has a very big problem (don't you have any other issue, like DNS resolve IP to hostname or vice versa, or thing like that?)

And I'm not sure to understand what is the relationship with your first question which was about 2 different systems.

Anyway, usually we never have this bad performance with only tenths of RFC function modules called.

[Former Member]

It's difficult to understand why a different number of parameters does change the performance

I came to this idea when I read in the mentioned sap note that internal tables passed as parameters are converted to xml and we can gain some performance if we pass them as TABLES parameters instead IMPORTING/EXPORTING (using table types).

So I thought that the number and type of the parameters could influence that time between each call, maybe I am wrong.

When I added 15 more tables as parameters that time was increased. That is why I thought the performance was related to the parameters.

And I'm not sure to understand what is the relationship with your first question which was about 2 different systems.

The issue is happening in one system and I had checked all the system parameters related to the parallel processing, it seems to be all ok.

Then I created a simple program in a different system to simulate the parallel processing and check the behaviour.

In my 'test program' all the RFCs (dummy FM, without any code, only parameters) in the loop were called in the same second.

I decided to include 15 more tables as parameters in my 'test program' and RFC, then the time was increased from 1 to 3 seconds between each call.

I checked the RFC calls in tcode STAD and it seems to be OK, the column Wait RFC is empty for all RFC calls.