Impact of Message-Size on XI Performance

[Former Member]

Hi all,

I am writing on my diploma theses with the topic "Developing a concept for generating realistic workloads for message-oriented middleware landscapes in order to perform loadtests".

During my work I came to the following question for which I hope to find an answer here:

What impact does a size of a message have on the performance of the XI?

It seems to me quite obvious that it must be something like: the larger the message the worse the performance, isn't it?

Do you have some quantitative information for me?

Can I group the messages somehow in small, medium, and large, where all messages in one group do have a similar behavior?

Thanks for your help.

Best Regards,

Sebastian

Message was edited by:

Sebastian Geissler

Message was edited by:

Sebastian Geissler

[Former Member · Accepted solution]

Hi,

The central tool for performance monitoring is the Runtime Workbench, which you call from the Integration Builder start page.

Yes, you can filter the message based on size. Check the following documentation for details.

<a href="http://help.sap.com/saphelp_nw70/helpdata/en/9e/6921e784677d4591053564a8b95e7d/frameset.htm">Performance monitoring</a>

The system displays the messages that meet the specified search criteria. The display returns the following results:

Performance Data

Message ID = ID of processed message

Size=Size of processed message

First and last time stamp (absolute)=First and last time stamp of message processing in absolute units

Processing Time=Difference between last and first time stamp in seconds

Cmponent=Component in which message processing took place

Processing Mode=Mode of message processing: synchronous or asynchronous

<Drilldown category>=Sender/receiver attribute(s) for data drilldown (if selected)

Note

If a message is processed on several systems and the clocks of these systems are not synchronized exactly, this can result in negative processing times.

Best Regards,

Tarun

[Former Member]

Hi Tarun,

thanks for your answers so far. They have been quite helpful (rating will follow).

But for the question regarding the grouping, my question was a bit ambiguous, I guess: I wasn't asking for the possibility to group messages in the monitoring tool.

My question was more targeting on the classification on messages regarding the generation of workload profiles.

Lets say, I do have six messages :

M1: 100 kB

M2: 150 kB

M3: 600kb

M4: 1MB

M5: 6MB

M6: 800 kB

is it a valid assumption to group M1 and M2 in the same class "small", valid in terms of they do have the same performance behavior, which is different from the performance-behavior as class "medium" with the messages M3, M4 and M6 and a different performance behavior as class "large", where M5 belongs to.

In other words will there be a boarder in messages size, where messages behave totally different than before?

Thanks and best Regards,

Sebastian

Message was edited by:

Sebastian Geissler

Message was edited by:

Sebastian Geissler

[Former Member]

Hi Sebastian,

<a href="http://help.sap.com/bp_bpmv130/Documentation/Operation/TuningGuide.pdf">SAP Exchange Infrastructure Tuning Guide</a>

Please refer to the section "3.4.1 Message Size" of the above document.It states ->

<i>Throughput in terms of bytes per second is much higher for larger messages. This is mainly due to the processing overhead for a single message (see figure). Assuming a linear model for the cost of proc-essing a single message of size s: T = a + bs, the throughput T increases linearly with message size for small messages and asymptotically reaches a maximum for large messages.

Furthermore, the Integration Engine stores messages in a compressed format (compression rates for XML messages are normally in the range of 70-80%). Therefore, applications should be designed to use larger messages (if possible). On the other hand, processing larger messages causes higher memory resource consumption. Therefore, you should consider 64bit platforms as there are no ad-dress space issues to limit memory usage.</i>

Best Regards,

Tarun