Hi experts,

I'm working in a complex ODM project where rules are applied against a large set of objects. Executing the HTDS is performing well (statistics in RES console are showing between 10-20 milliseconds as average).

However, statistics in the client side for the roundtrip execution (including JSON content serialization/deserialization) is around 3-4 seconds.

So, the reason is probably due to the large JSON payload. Do you ever hit a similar problem in an ODM project? Is there any optimization or server tunning that may help?

• some configuration setting in DecisionService.war or in the liberty profile ??
• How to use compression to reduce the size of the payload ??
• configuring DecisionService in a set of HTTP servers for load balancing the JSON processing? Can then HTDS implement a remote call to the XU in a different server profile without JSON serialization? (note that the XU can not be replicated in every HTTP server due to licensing constraints) 

 Any other suggestion is welcome.

thanks.

• Content-Type: application/json
• Content-Encoding: application/gzip

Hi experts,

I'm working in a complex ODM project where rules are applied against a large set of objects. Executing the HTDS is performing well (statistics in RES console are showing between 10-20 milliseconds as average).

However, statistics in the client side for the roundtrip execution (including JSON content serialization/deserialization) is around 3-4 seconds.

So, the reason is probably due to the large JSON payload. Do you ever hit a similar problem in an ODM project? Is there any optimization or server tunning that may help?

• some configuration setting in DecisionService.war or in the liberty profile ??
• How to use compression to reduce the size of the payload ??
• configuring DecisionService in a set of HTTP servers for load balancing the JSON processing? Can then HTDS implement a remote call to the XU in a different server profile without JSON serialization? (note that the XU can not be replicated in every HTTP server due to licensing constraints) 

 Any other suggestion is welcome.

thanks.

Hi Edu,

Yes you can do this with just headers. I did it back in 2017 using SoapUI and it was compressing my 10Mb input payload down to 85k so there was a saving on the upload time. I did ask at the time and there was no way to compress the ODM output payload so the response was a 10Mb transfer. But it's still worth doing. If it is a real issue for you then you could compress the output yourself at the end of the ruleflow but you will only need this if your parameter is in_out.

I don't have the original SOAP project any more but I have a screenshot that shows:

Content-Encoding: gzip

Accept-Encoding: gzip,deflate

So you should find the settings in Postman or from a quick web search quite easily.

• Content-Type: application/json
• Content-Encoding: application/gzip

Hi experts,

I'm working in a complex ODM project where rules are applied against a large set of objects. Executing the HTDS is performing well (statistics in RES console are showing between 10-20 milliseconds as average).

However, statistics in the client side for the roundtrip execution (including JSON content serialization/deserialization) is around 3-4 seconds.

So, the reason is probably due to the large JSON payload. Do you ever hit a similar problem in an ODM project? Is there any optimization or server tunning that may help?

• some configuration setting in DecisionService.war or in the liberty profile ??
• How to use compression to reduce the size of the payload ??
• configuring DecisionService in a set of HTTP servers for load balancing the JSON processing? Can then HTDS implement a remote call to the XU in a different server profile without JSON serialization? (note that the XU can not be replicated in every HTTP server due to licensing constraints) 

 Any other suggestion is welcome.

thanks.