Performance in Parallel Processing

[Rocky1]

Hi,

My program model is as follows:

I have a RFC FM(ZRFC_BACKGROUND) that will be called in BACKGROUND TASK and

This FM in turn will call a child process(another RFC FM(ZRFC_CHILD)) in parallel for packages that are created in ZRFC_BACKGROUND

We can use around 10 work processes that belongs to one server group, for parallel processing

Facts regarding Packaging:

• One Package has 4 retry attempts due to locking issues.
  • if there is an error in child process, the package is held back in FM : ZRFC_BACKGROUND and re triggered after sometime
• Locking issues are frequent.

Data in DB tables on which I will put SELECT query:

• Header        Table LIKP (With approximately 1 Million Entries) (My select query will fetch around    800 entries)
• Item             Table LIPS (With approximately 6 Million Entries) (My select query will fetch around 10000 entries)
• Partner        Table VBPA (With around 3 Million Entries) (My select query will fetch around 3000 entries)
• Reference   Table LIPSRF (With around 74 million entries) (My select query will fetch around 10000 entries)

My QUESTION is which of the following approach is better:

•      To put LIKP select query in the first background FM ZRFC_BACKGROUND and pass it to ZRFC_CHILD and do remaining query in ZRFC_CHILD
•      OR to put all the select query in ZRFC_BACKGROUND

Please keep following things in mind :

• As we know it is not recommended to pass huge tables in RFC as it may increase the network load (In case of select query in ZRFC_BACKGROUND, network load will be more)
• But it is also not recommended to do DB select several times (In case of select query in ZRFC_CHILD, db read time will be more )

On the basis of aove facts, please suggest which is the better approach.

Regards

Rocky

[former_member184455]

Hi Rocky,

Why do you have locking issues? In the worst case, parallel processing will not help at all or even slow down the process if there are too many locks. Ideally, parallel tasks should not collide with each other. Which tables do you update / insert?

How big are your packages? How long do they take to process?

From the database point of view, it will not make a big difference whether you select 1 x 10000 entries or 100 x 100 entries. On the other side, if your second approach leads to additional database accesses as compared to the first one, this of course could slow down the process.

Best Regards, Randolf

[ThomasZloch]

What is the reason to implement parallel processing? If your queries are index-supported then they should return quite quickly. It seems that you can use a join select, as the tables are related.

Apart from this, in order to split the overall task into evenly sized packages you could read just LIKP-VBELN in ZRFC_BACKGROUND and then call the ZRFC_CHILD processes with the lists of VBELNs to be processed.

Thomas