2013 May 20 6:58 AM
Hi,
We have detected with have a high execution time when our system executes program SAPLQOWK.
We are performing a IDocs massive load and we have performance issues.
also we have detected a high process time during the execution of program SAPLARFC .
Can someone help us?
Thanks a lot and best regards, Sapera
2013 May 21 8:39 AM
Hi,
Maybe you are heavily using the qRFC outbound queue by not bundling (packing) several IDocs into one LUW (logical unit of work). That is, there is one COMMIT WORK per IDoc?
Best Regards,
Randolf
Hi,
We have detected with have a high execution time when our system executes program SAPLQOWK.
We are performing a IDocs massive load and we have performance issues.
also we have detected a high process time during the execution of program SAPLARFC .
Can someone help us?
Thanks a lot and best regards, Sapera
2013 May 20 7:38 AM
Did you check for any SAP Notes?
I just did....and found lots of notes which addresses performance problem.
Search in SAP portal with the search term as "SAPLARFC"
2013 May 20 4:19 PM
We have two different problems one is with SAPLARFC and the other with SAPLQOWK.
With SAPLARFC you are rigth there are a lot of notes, but the process which is consuming a lot of time is SAPLQOWK and for this we haven´t found any interesting note.
So, could someone help us?
Thanks a lot sapera
2013 May 21 7:20 AM
Did u check the SAP note Note 1485789 - QRFC: Long running processes in SM50
This was suggested by Swanand also.....is it applicable for you?
2013 May 20 4:30 PM
Hello,
For report SAPLQOWK check Note 148578. System resources may not be used correctly.
For report SAPLARFC check Note 726148.
best regards,
swanand
2013 May 20 5:36 PM
You also might want to try running it in SE30 and ST05 see if you have DB problems or Processing problems.
Neal
2013 May 21 6:58 AM
Hi,
We have checked the STAD transaction and we have detected a high RFC time, but we can´t detect the program is using it.
Any idea?
thanks a lot, sapera
2013 May 21 8:39 AM
Hi,
Maybe you are heavily using the qRFC outbound queue by not bundling (packing) several IDocs into one LUW (logical unit of work). That is, there is one COMMIT WORK per IDoc?
Best Regards,
Randolf
2013 May 21 8:53 AM
Hi,
Yes, we execute idoc per idoc with the option trigger immediate and transfer idoc inmmediately.
Our client wants to use these option alugth we know that from the performance point of view is not the optimal way.
So any idea how we can resolve our performance issues?
Thanks a lot and best regards, sapera
2013 May 21 9:45 AM
Hi,
Processing single objects in an own LUW leads to high load and many round-trips. Try to discuss with your client her/his requirement of single processing the IDocs. The client has to decide whether this is more important than reasonable performance.
Best Regards,
Randolf
2013 May 21 5:26 PM
Hi,
In case the customer doesn´t want to change the requirements, do you now any way to improve the performance?
thanks a lot, sapera
2013 May 22 8:33 AM
2013 May 22 8:46 AM
2013 May 22 8:45 AM
Hello,
You need to check the status of QOUT scheduler in SMQS when the issue occurs. If you have enough free DIA work processes you can increase the max conn. for the RFC destination.
And if the data amount is very large, you may consider to increase some parameter settings as mentioned in note 384971. Please also do housekeeping for RFC tables so that DB performance is good enough.
Help this can help you.
Thanks.
Jim
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |