PI performance issue for a single Interface

[Former Member]

Hi experts,

In a PI 7.0 system we are experiencing very bad performance for a single interface. It is sending daily a 1MB payload message and it takes about 10 seconds to process (this is OK), but on fridays a bigger set of records is sent, about 45MB payload. It takes more than 2 days to process the message!!!

I have been doing some research and I see that the bottleneck is in the Integration Engine. I have compared it with other interfaces that sent huge messages as well, and I only see a point that I don´t understand. While other messages, of about 43MB payload (read it in SXMB_MONI, parameter <SAP:MessageSizePayload>) has a message size of 15MB in field MSG_SIZE of table SXMSPMAST, the problematic interface, with a <SAP:MessageSizePayload> parameter of 45MB, has SXMSPMAST-MSG_SIZE of 19MB.

Can somebody explain me the relationship between these two sizes and and idea on what can I do in order to reduce MSG_SIZE?

Thanks in advanced for your help

Javi

[baskar_gopalakrishnan2 · Accepted solution]

If it is feasible, modify the design to go with smaller volume of data in each interfaces. Example if your interfaces deal with jdbc, query for smaller volume of records to reduce the size of the message. Similarly if you have file conversion then set recordsets per message like 500 records per file. Also you might want to consider using tuning parameter to allocate special queue & memory size handle per message in transaction sxmb_adm. Search forum for tuning parameters configuration in SXMB_ADM

[Former Member · Accepted solution]

Hi

I had similar problem, it may not related to your problem but here is what I experienced.

It turned out, one of the PI developer had 10 secs delay in one of the UDF in mapping.

Regards.

[prateek]

For your performance problem, have you created a separate XBTL* or XBTM* queue for processing large messages?

MessageSizePayload refers to the size of actual payload. This value is available in bytes. What is the exact value you see there?

Regards,

Prateek Raj Srivastava

[Former Member]

Hi Prateek,

This is the size:

<SAP:MessageSizePayload>45035262</SAP:MessageSizePayload> <SAP:MessageSizeTotal>19649</SAP:MessageSizeTotal>

Queues XBTL and XBTM are active but there is no EO_MSG_SIZE_LIMIT parameter, therefore large messages are not picked up in this queus.

I have seen that messages with payload up to 43MB are performing just fine using using XBTO. Which size do you recommend that I put on EO_MSG_SIZE_LIMIT? 40.000 for example?

And setting this parameter will actually speed up this interface or will just slow it even more, because this queue has less priority?

Thank you all for your usefull comments.

[Former Member]

Hi

Which step is taking the most of the time, go to details in SXI_MONITOR and check the time for each step in runtime node.

Is it getting stuck in Queue and remain there for 2 days?

Regards.

[Former Member]

Hi Hikmet,

The problematic step is the message mapping. It is a graphical mapping, a lot of fields are mapped, but there is no look-ups. The mapping is working just fine when the payload size is small, but when the message is bigger, performance goes down.

[prateek]

This parameter takes value in bytes. So if you want to put 20 MB, you need to put 20480. Note that if you set this parameter to 20 MB, it woudl mean that any message exceeding 20 MB will be put to large queues like XBTL*.

If you have large number of such messages which could get executed in parallel, then it could affect the performance adversely.

Regards,

Prateek Raj Srivastava

[Former Member]

Ok, this parameter would increase the overall performance. But this interfaces in particular would be sent faster if it is processed in the XBTL queue?

[prateek]

I guess it won't take 2 days. How about trying it and giving it a shot?

Regards,

Prateek Raj Srivastava

[Former Member]

Hi

Even though they say graphical mapping is faster, I would go with XSLT, you got more control..

Regards.