GS.Chandra N wrote:
Hi,
I'm testing the qpid distribution using the pub-sub examples that come as
part of the python distribution and have certain doubts
1. Is ttl handled only by brokers ? At which points can a message be
dropped? Is there a way to track how many such messages where dropped? I'm
trying to look at this feature as a way to reduce bandwidth euqirements for
slow clients for data which is useless after max n secs. Is this the way
this feature is supposed to be used?
Only the broker looks at ttls, and within a broker, only the queue will
drop messages based on ttl. If the message lingers in a queue for longer
than the ttl, then the message will be discarded rather than being
delivered.
I don't believe there is currently a way to track how many messages are
dequeued due to ttl vs dequeued due to delivery. It sounds like an
excellent candidate for a feature request though. Feel free to file a
JIRA for one. ;)
2. The original publisher sample sets the message destination to be the
amq.topic. I tried modifying the publisher to send the message to the
amq.fanout exchange. (session.message_transfer(destination="amq.fanout",
message=....).
But my client which subscribes from the amq.topic exchange does not get the
message. Why is this so? My understanding was that fanout would send a copy
to ALL queues in the system?
It sends to all queues bound to the amq.fanout exchange, but you still
need to explicitly bind your queue to amq.fanout for it to receive
messages sent there.
3. How expensive are multiple subscriptions using amq.headers exchange? I'm
trying to evaluate a use case where there would be hundreds (600-800) of
clients per broker, with each having multiple subscriptions for multiple
data items (100 or so). I'm not sure if its better to create a single HUGE
subscription for all the data or multiple ones. Or is it better to simply do
all the filtering at the client end? (WAN links so amount of data
transffered is a sensitive issue). Any guidance would be really appreciated
here.
Am I correct in thinking that the total number of subscriptions would be
(600-800)*100, i.e. 60,000-80,000 queues? If so that may be a lot, but
the C++ guys can probably give you more details.
4. What is the preferred way to measure latency / throughput at each point
of conduct ? Does qpid have any special headers that can track this
automatically or is should this be done by the app itself?
I believe the cpp build includes a latencytest utility that might be of
use, or at least a good example to work from. I don't know firsthand,
but I believe its testing is based on round trip times at a given
(fixed) throughput.
There are two tricky issues when measuring latency: clock
synchronization, and the latency/throughput tradeoff. The clock
synchronization issue can be avoided by measuring the complete round
trip time of a full request/response. This way you're comparing two
timestamps from the same machine, and so you don't need to worry about
precisely synchronizing clocks on two separate machines.
The latency/throughput tradeoff happens because at higher throughputs
various queues and I/O buffers start backing up, and this adversely
effects latency. This is why we measure latency at a fixed throughput.
Without a fairly specialized setup I believe it would be difficult to
precisely measure the latency at each point of conduct.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
