Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

qRFC processing v/s Parallel Processing

Former Member
0 Likes
1,703

Hi all,

I am having a requirement to update mass data in custom tables (Z* & Y*). For this I have couple of options to be used to update the data in tables.

1. Using qRFC.

2. Using Parallel Processing.

So now I am bit confused which method will be good for updating the data base tables in terms of performance wise and scalability.

As per my knowledge parallel processing will be good in the performance wise but not sure how it will be good compared to qRFC method.

Will be very helpful if I can get the advantages and disadvantages of using the both methods so that I can propose the same and which method will be good to use.

Regards,

Santosh L.G

1 ACCEPTED SOLUTION
Read only

umashankar_sahu
Active Participant
0 Likes
986

Dear Santosh,

As per my knowledge parallel processing will be good in the performance, I also agree with that.

But you need to check when more than one connection are made at the same time to update the same table than, data base should process the one record and it should lock the table and another connection's to update the same table should hold in queue . I think it is property of standard data base. just check

2 REPLIES 2
Read only

yuri_ziryukin
Product and Topic Expert
Product and Topic Expert
0 Likes
986

Hello Santosh,

normally parallel processing is implemented via aRFC (asynchronous RFC).

qRFC is another method of aRFC that simply allows to keep RFC processing in a defined sequence.

Both are more or less equal in terms of performance, however (not 100% sure) qRFC scheduler may cause a little overhead.

Normal aRFCs are good if you don't want to have very flexible resource management. You simply run your job, it spawns multiple RFC calls up to a certain number and then keeps it running with this number (starting new when previous executions are finished).

In the qRFC you can define parallelization degree with the number of queues.

Let's say you put all your RFCs into the following queues (you change queue in turn that number of entries is evenly distributed):

- ZQUEUE1 (500 entries)

- ZQUEUE2 (500 entries)

- ZQUEUE3 (500 entries)

- ZQUEUE4 (499 entries)

Now your RFCs will be processed one by one with 4 parallel processes. Important in qRDC that you can stop/start each of the queues separately. E.g. if you have a peak time and you need more resources for your normal users, you go to trx. SMQR and deregister qeueus 1-3. Only queue 4 will be running.

Another good thing - reprocessing possibility. If your RFC dumps for some reason, the queue will be stopped and you can reprocess your entry later on when you fixed your coding error or whatever else...

So, simplier tasks - aRFC. More complex tasks with better resource management - qRFC.

Kind regards,

Yuri

Read only

umashankar_sahu
Active Participant
0 Likes
987

Dear Santosh,

As per my knowledge parallel processing will be good in the performance, I also agree with that.

But you need to check when more than one connection are made at the same time to update the same table than, data base should process the one record and it should lock the table and another connection's to update the same table should hold in queue . I think it is property of standard data base. just check