cancel
Showing results for 
Search instead for 
Did you mean: 

SAP .NET Connector performance

Former Member
0 Kudos

My performance for my SAP .NET connector project is horrible. Takes about 5x time of the previous DCOM project. I've traced the slowdown down to the actual SAPInvoke DLL call so there is nowhere where I have the power to tune the software. Why is this so slow? Is there plans to improve performance?

Thanks, Robert

Accepted Solutions (0)

Answers (1)

Answers (1)

David
Advisor
Advisor
0 Kudos

Hello Robert,

Might I suggest that you post this question in the SAP NetWeaver Platform, WEB AS, or Exchange Infrastructure discussions? This forum is for suggestions to improving the SDN site itself such as look and feel or functionality you would like to see. The other topic area forums are monitored by members of the respective Product Management community who have expertise in the area a person might be having trouble with and also appreciate the type of feedback you want to provide so they can engineer a better product. It isn't likely that they will see if here unless they happen upon it while browsing this topic area.

Kind Regards,

David Branan

SDN Platform Team

Former Member
0 Kudos

I experience the very same problem. When I execute the query in my production environment, it takes up to 3,5 seconds. The SAPInvoke from the .NET connector takes up to 4 minutes to make the function call with the same params, same results.

Moreover, in the acceptance environment, we do not suffer from this delay.

Regards,

Wouter Ramon

reiner_hille-doering
Active Contributor
0 Kudos

We have done interal comparisons and found NCo almost never be slower than DCOMCC.

There are some points that should be considered however:

- The creation of a Proxy instance is usually time consuming, because the underlying MS Soap proxy creates, compiles and loades temporary DLLs for XML serialization. This can be compensated by keeping the proxy instance for longer period. In most cases it's anyway stateless.

- Some of the new nested data types are serialized in XML. This also needs the creation, compilation and loading of XML serializer code. In contrast to 1.0, NCo 2.0 optimizes this behavior by caching the XML serializers.

In most cases the performance mainly depends on the backend and the design of the API. NCo cannot influence the processing speed, but you can make sure that the minimal set of required data is transfered over the wire and only really needed data is processed at the backend.