qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Li <andr.deve...@gmail.com>
Subject Flow control behavior of fanout exchange
Date Thu, 29 Oct 2009 18:06:33 GMT
Hi,

We ran into strange differences of flow control behavior of fanout exchange.
We use configuration with one publisher and 10 subscribers.

1)On some machines, publisher throughput will be higher than subscriber
throughput, and eventually the queue will overflow and throw an exception.
This is, as I understand, the expected behavior - publisher has entire 1
Gbit bandwidth to itself, whereas subscribers share it, so they have lower
theoretical limit. We've coded a simple flow control scheme to manage this.

2)However, on other machines we installed the broker, publisher and each
subscriber throughput seem to move in sync. There is little buffering in the
queue, and the overflow never happens. While the lack of overflow is
convenient, bandwidth utilization is 2-4 times lower compared to broker
machines exibiting behavior (1). In (1), combined output bandwidth utilized
by subscribers is 80-90% of 1Gbit available. In (2), it's 20-40%, depending
on the machine and latency to client.

All broker machines use the same OS version and broker 0.5 binaries with
default broker config. We can't figure out what is causing this difference
in behavior. We did seem to induce behavior (2) on machines (1) by running
unrelated workload concurrently that strongly competed for bandwidth.

Has anyone else run into the same issue? Or has any idea about what might
cause this? Any help or suggestions would be greatly appreciated.

Thanks,
Andy

Client Details:

The publisher and subscriber clients are the same in both cases and run on a
separate machine. We're using asynchronous send and sync() every 1000
messages. Listeners use ACCEPT_MODE_NONE and FlowControl::unlimited().
Message size is random, linearly distributed between 500-1500 bytes.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message