Performance considerations for mass creation scenarios when using OData and SAP Gateway

[Tobias_Griebe]

The main focus of OData and SAP Gateway is to provide a slim and lightweight protocol for data consumption. In the majority of use cases, CREATE operations are performed for single entities only. However, there are valid scenarios where it’s necessary to create multiple entities simultaneously.

As an example, we will create a new service "ZGWSAMPLE_MASSINSERT_SRV" as a redefinition of the existing "GWSample_Basic" service, which is available as part of SAP Gateway Foundation (component SAP_GWFND) NW Release 7.40 SP09 and later. This service uses the EPM data model and we will create new products for an existing business partner. Assuming we need to create 100 new products with one single call, the easiest way would be to use a $batch request to combine all 100 POST calls into a single service call:

Adding the sap-statistics=true option at the end of the URI provides more details on how much processing time was required in the different SAP Gateway related layers. The table below shows the runtime in milliseconds for the creation of 1 to 2500 products:

products	gwtotal	gwhub	gwbe	gwapp
1	284	98	18	168
10	804	292	80	432
100	6456	2384	641	3432
500	33699	11952	3169	18578
1000	73870	25032	6515	42323
2500	252835	81069	17288	154478

Let's have a look at what is happening behind the scenes when creating 100 products that way:

- 100 times de-serializing the JSON-payload while parsing the request-payload

- 100 times single request processing in the SAP Gateway Hub system

- 100 times single request processing in the backend system

- 100 times serializing the JSON-payload to generate the response-payload

All these steps are necessary because each changeset operation has to be handled separately!

This becomes even more obvious once we look into the SAP Gateway performance trace (Transaction: /n/iwfnd/traces):

In this example, we’ve created 10 new products and can see that for each new product the CREATE_ENTITY method is called.

The table shows that roughly 40% - 45% of the overall runtime per service call is SAP Gateway related overhead. Assuming that the application related coding is already optimized, the critical key figure to improve performance further is to minimize the SAP Gateway related overhead.

This can be achieved by modelling an additional entity set that will receive a list of products and create them via the deep-insert feature. Therefore, we will create a new entity named "ProductMassInsert" with the respective entity set "ProductMassInsertSet". Furthermore, we'll also need an association defined by the principal entity "ProductMassInsert" and the dependent entity "Product" and the cardinality 1:M. The association is needed to create the deep-insert functionality and will be named "ToProducts". All we need to do now is redefine the CREATE_DEEP_ENTITY method inside the *DPC_EXT class to handle the creation of the products.

The call to create the list of products using the deep-insert mechanism will look like this:

This is what is now happening behind the scenes when creating 100 products within one deep-insert request:

- only 1 time de-serializing the JSON-payload while parsing the request-payload

- only 1 time single request processing on the SAP Gateway Hub

- only 1 time single request processing on the backend system

- only 1 time serializing the JSON-payload to generate the response-payload

products	gwtotal	gwhub	gwbe	gwapp
1	299	104	19	176
10	507	104	23	381
100	3186	190	68	2929
500	16048	553	252	15244
1000	36517	1016	490	35011
2500	128848	2345	1211	125292

As to be expected, the application runtime in the backend is similar as the coding hasn’t been further optimized.

The effective performance boost in the given scenario is about 90% performance increase in the SAP Gateway Hub and about 90% in the backend system, already starting at 100 entities. As performance follows a linear pattern in the non-optimized scenario, it will even improve with a higher amount of entities to be created. This won't have any effect on the performance of the backend application itself, but importantly reduces the SAP Gateway overhead to a minimum.

Looking again at the SAP Gateway performance trace (Transaction: /n/iwfnd/traces) we can see that no matter how many products are being created with this deep-insert approach, the CREATE_DEEP_ENTITY method is only called once.

In the given example we could reduce the overall runtime in the CREATE scenario by 50% !!!

Worth reading: Details about some new features in SAP Gateway 2.0 SP09 - Performance Improvements on $batch (Change Set at Once/Change Set in Defer Mode)