cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of adaptive RFC.

Former Member
0 Kudos

Hi,

I am facing severe performance issues while executing adaptive RFCs in my Java Web Dynpro app (depending on the size of the table). I am already using "TASK SCOPE" code-

AcknowledgeModel watchModel = (AcknowledgeModel)WDModelFactory.getModelInstance(AcknowledgeModel.class, WDModelScopeType.TASK_SCOPE); 
Z<name>_Input input = (Z<name>_Input) watchModel.createModelObject(Z<name>_Input.class);

I have to execute the RFC call for each row of a table, and then check the return value, if the condition is true, then execute another RFC call.

Problem is the average number of rows in this table is around 1000 rows.

For now my JCo connection values are...

ModelData-

Maximum Pool Size:  10
Maximum Connections: 12, 00 
Connection Timeout (msec.):  20,000
Maximum Waiting Time (msec.):  30,000

RFC Metadata-

Maximum Pool Size:  2
Maximum Connections: 10 
Connection Timeout (msec.):  30,000
Maximum Waiting Time (msec.):  10,000

I tried searching, couldn't find any relevant threads...

Thanks

Accepted Solutions (1)

Accepted Solutions (1)

former_member197348
Active Contributor
0 Kudos

Hi Srinivas,

Increase Max. Pool size and Max. Connections.

In the RFC execute method, add this line of code.

wdContext.nodeOutput().invalidate();
wdContext.currentRfc_InputElement().modelObject().modelInstance().disconnectIfAlive();

Regards,

Siva

Former Member
0 Kudos

Hi

I added the following code.

wdContext.nodeOutput().invalidate();
wdContext.currentZ<name>_InputElement().modelObject().modelInstance().disconnectIfAlive();

,

right after the execute() in the try/catch.

I also increased the

Max connections to 100, 000
Pool size to 200 (that is the max possible)

Connection Timeout (msec.):  20,000
Maximum Waiting Time (msec.): 30,000

I don't see any change, still same performance problems (taking a lot of time in minutes depending on the number of rows for the table).

Any more ideas...

Edited by: srinivas M on Sep 14, 2009 6:15 AM

Former Member
0 Kudos

Hi,

I'd suggest first, not calling the back-end 1000 times. Call only once, with 1000 elements. It would be a lot more efficient, thou I think the user will not change 1000 lines at a single time.

If you explain what you doing and what are you trying to achieve, maybe me or someone can help you to change the way you are calling the back-end.

As far as I know, even if you get a "good performance", which I think you wont doing it this way, I'm quite sure there would be better ways to do it.

Regards,

Daniel

Former Member
0 Kudos

>

> Hi,

>

> I'd suggest first, not calling the back-end 1000 times. Call only once, with 1000 elements. It would be a lot more efficient, thou I think the user will not change 1000 lines at a single time.

>

> If you explain what you doing and what are you trying to achieve, maybe me or someone can help you to change the way you are calling the back-end.

>

> As far as I know, even if you get a "good performance", which I think you wont doing it this way, I'm quite sure there would be better ways to do it.

>

> Regards,

>

> Daniel

I have a table at run time (on average has 1000-1200 rows). For each row, I have to execute RFC and check a condition, if the condition is true, then I have to run another RFC.

Can you elaborate on what you said "not calling the back-end 1000 times. Call only once, with 1000 elements. It would be a lot more efficient, thou I think the user will not change 1000 lines at a single time."

Thanks

Srinivas

Former Member
0 Kudos

Hi,

I'll try to make myself clear.

Calling the backend a thousand times "at once" is not a good idea. Even more, when that can become two thousands, if your "condition" is true.

Instead of doing it "per row", do it "per node" - Send the whole data in a List to be processed. Also, try to use something smart, so you only send stuff that actually changed.

About "the second call" - I'd suggest change the logic in the back-end, if that condition is true, the back-end process this other piece of logic and you can have only one call, instead of one thousand or more.

Regards,

Daniel

Answers (1)

Answers (1)

ravindra_bollapalli2
Active Contributor
0 Kudos

hi,

in addition to the above content,

here the one blog what to be done for increasing the performance in webdynpro applications

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/11c3b051-0401-0010-fe9a-9eabd9c216de&override...

let me know u need any further info

ravindra