topic Performance in Parallel Processing in Application Development and Automation Discussions

Performance in Parallel Processing

Rocky1 — Fri, 14 Mar 2014 11:10:53 GMT

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

Re: Performance in Parallel Processing

former_member184455 — Fri, 14 Mar 2014 11:48:46 GMT

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

Re: Performance in Parallel Processing

ThomasZloch — Fri, 14 Mar 2014 11:56:33 GMT

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