ABAP Proxy performance

[Sandra_Rossi]

Hi

I have an performance issue with ABAP Proxy via SAP PO.

I have exposed a SOAP service in SAP PO. This service call SAP S/4HANA (on-premise) with and Sproxy service. There is currrently no logic at all in the proxy - it just returns "Hi i am here".....

But the service has a runtime of 115 ms. When i check PO monitor, i can sse that first 10 ms is used in SAP PO. The rest of the runtime is used in the SAP S/4HANA (ABAP system)!

Does anyone knows how we can lower the runtime in ABAP? Actually we need to lower by at least factor 10. Otherwise the consuming systems cannot use this service.

Any ideas on what to do? Increase CPU, RAM or anything else?

[Sandra_Rossi]

Just to say, the ABAP part for doing "nothing" seems to be a lot (database accesses for technical/configuration stuff), but is probably relatively small compared to the total time when the ABAP logic will be added (other database accesses to operate on ERP data).

[jakob_steen-petersen]

Hi Sandra

Actually i have tried to build both. Also i tried to create a version that is able to sumilate a bundled request of 1.000 objects. With 1.000 Database access in one call.

1 call with Hello World return is - as said - 115 ms

1 call with 1.000 objects and 1.000 DB access calls is ~1.000 ms

So my point is; SAP PO can pass a call very quick. SAP ERP has something that really slows down the performance. Someting that "wraps the call" and slows it.

[Sandra_Rossi]

As I said, ABAP kernel does "database accesses for technical/configuration stuff", so it can be "a lot", but is "probably relatively small compared to the total time when the ABAP logic will be added".

I'm not expert, so I'll let SAP experts share their thoughts about kernel performance.

[Ryan-Crosby]

You aren't going to get a 10x fold decrease in runtime by providing more CPU/RAM. The runtime you are experiencing (a tenth of a second - hardly a lot) is going to be consumed entirely by the underlying proxy framework where it is going to direct the call to the appropriate service provider (proxy class). If the consuming systems require a hundredth of a second, then I suspect there is something else at play here, and the onion needs to be peeled back further...

[pamai]

Good morning Jakob,

my gutt feeling is that 115 ms isn't actually that bad and I doubt throwing RAM or CPU at the problem would help. You would further need to investigate where the time is lost - e.g. network latency, round trips between the two integration engines - but I would doubt you can cut the response time by factor 10 as this would almost be eaten up the network time. Run a performance trace on S/4 side for the web service and then see whether the issue is with the time spend in the actual web service or in the chit chat of the components involved in the integration engine to integration engine communication (this would be my bet - then you would need to do some tuning here).

Cheers

Patrick

[jakob_steen-petersen]

Hi Patrick

Yes i agree 115 ms is basically ok (in production we are down on 78ms). But the service we have build, is replacing a mainframe service with a avarage responsetime of 2ms (!).

So my approach is to investigate if we can do anything in order to come down to at least 20 ms. If not we will have to look into another solution.

But as a you see - we have quite a way if we should "compete" with the old solution.

//Jakob

[pamai]

Could you provide some ST03 performance data for this web service ?