qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kim van der Riet (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PROTON-1786) Multiframe transfer wire traffic patterns differ substantially
Date Wed, 07 Mar 2018 20:22:00 GMT

     [ https://issues.apache.org/jira/browse/PROTON-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kim van der Riet updated PROTON-1786:
-------------------------------------
    Description: 
This is not a bug (although it could become one), but rather an observation of large message
transfer patterns observed using Wireshark while running Qpid Interop Test's amqp_large_content_test.

The test sends large messages through a broker (in this case, dispatch router) of size 1MB
and 10MB.

I hope to add other observable patterns from other clients if they are significant. If there
is consensus that this is a potential large message transfer efficiency issue, then this Jira
can be a placeholder for this issue.

In  this test, the receiver is using TCP port 59806 and the sender port 59808. The router
is using the standard AMQP port.
h2. C++ client:

The client in this case uses the Proton C++ API and is based on the SimpleSender.cpp example.
To isolate the traffic from this client, use the following filter in Wireshark:
{noformat}
amqp.performative == transfer && tcp.srcport == 59808{noformat}
It can be seen that although there is a large message being sent, the sender appears to be
restricted to a single transfer of 16kB or a 64kB frame containing 4 transfers (very occasionally,
2, 3 or 5 transfers) - for example:
{noformat}
35	1.972620	::1	::1	AMQP	16470	transfer
1177	2.032878	::1	::1	AMQP	65550	transfer transfer transfer transfer
{noformat}
h2. Dispatch Router:

This uses Proton through its native C interface. To isolate the traffic from the router to
the receiver, use the following Wireshark filter:
{noformat}
amqp.performative == transfer && tcp.dstport == 59806{noformat}
The traffic for this broker looks very different. Each frame contains only a single transfer,
and the size of the transfers differ widely, from 196 bytes to the full 64kB max. I am assuming
that the router is sending on message content it has received as soon as it becomes available
no matter the size.

  was:
This is not a bug (although it could become one), but rather an observation of large message
transfer patterns observed using Wireshark while running Qpid Interop Test's amqp_large_content_test.

The test sends large messages through a broker (in this case, dispatch router) of size 1MB
and 10MB.

I hope to add other observable patterns from other clients if they are significant. If there
is consensus that this is a potential large message transfer efficiency issue, then this Jira
can be a placeholder for this issue.

In  this test, the receiver is using TCP port 59806 and the sender port 59808. The router
is using the standard AMQP port.
h2. C++ client:

The client in this case uses the Proton C++ API and is based on the SimpleSender.cpp example.
To isolate the traffic from this client, use the following filter in Wireshark:
{noformat}
amqp.performative == transfer && tcp.srcport == 59808{noformat}
It can be seen that although there is a large message being sent, the sender appears to be
restricted to transfers of 16kB or a 64kB frame containing 4 transfers (very occasionally,
2, 3 or 5 transfers) - for example:
{noformat}
35	1.972620	::1	::1	AMQP	16470	transfer
1177	2.032878	::1	::1	AMQP	65550	transfer transfer transfer transfer
{noformat}
h2. Dispatch Router:

This uses Proton through its native C interface. To isolate the traffic from the router to
the receiver, use the following Wireshark filter:
{noformat}
amqp.performative == transfer && tcp.dstport == 59806{noformat}
The traffic for this broker looks very different. Each frame contains only a single transfer,
and the size of the transfers differ widely, from 196 bytes to the full 64kB max. I am assuming
that the router is sending on message content it has received as soon as it becomes available
no matter the size.


> Multiframe transfer wire traffic patterns differ substantially
> --------------------------------------------------------------
>
>                 Key: PROTON-1786
>                 URL: https://issues.apache.org/jira/browse/PROTON-1786
>             Project: Qpid Proton
>          Issue Type: Task
>            Reporter: Kim van der Riet
>            Priority: Major
>         Attachments: dispatch.multiframe.07.pcapng
>
>
> This is not a bug (although it could become one), but rather an observation of large
message transfer patterns observed using Wireshark while running Qpid Interop Test's amqp_large_content_test.
> The test sends large messages through a broker (in this case, dispatch router) of size
1MB and 10MB.
> I hope to add other observable patterns from other clients if they are significant.
If there is consensus that this is a potential large message transfer efficiency issue, then
this Jira can be a placeholder for this issue.
> In  this test, the receiver is using TCP port 59806 and the sender port 59808. The
router is using the standard AMQP port.
> h2. C++ client:
> The client in this case uses the Proton C++ API and is based on the SimpleSender.cpp
example. To isolate the traffic from this client, use the following filter in Wireshark:
> {noformat}
> amqp.performative == transfer && tcp.srcport == 59808{noformat}
> It can be seen that although there is a large message being sent, the sender appears
to be restricted to a single transfer of 16kB or a 64kB frame containing 4 transfers (very
occasionally, 2, 3 or 5 transfers) - for example:
> {noformat}
> 35	1.972620	::1	::1	AMQP	16470	transfer
> 1177	2.032878	::1	::1	AMQP	65550	transfer transfer transfer transfer
> {noformat}
> h2. Dispatch Router:
> This uses Proton through its native C interface. To isolate the traffic from the router
to the receiver, use the following Wireshark filter:
> {noformat}
> amqp.performative == transfer && tcp.dstport == 59806{noformat}
> The traffic for this broker looks very different. Each frame contains only a single transfer,
and the size of the transfers differ widely, from 196 bytes to the full 64kB max. I am assuming
that the router is sending on message content it has received as soon as it becomes available
no matter the size.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message