qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Peter <richard.pe...@raytheon.com>
Subject Re: C Broker Availability Problem
Date Thu, 09 Jun 2011 13:57:04 GMT
On 06/09/2011 08:17 AM, Gordon Sim wrote:
> On 06/08/2011 01:08 PM, Richard Peter wrote:
>> Hi,
>> The issue I'm having is when a client producer sends message based on
>> user interaction. The message causes a screen to pop up on another
>> workstation. Usually the pop up is instantaneous, sometimes though it
>> takes up to 2 minutes for the message to get to the other workstation.
> Have you noticed latencies that large for any other messages in the 
> system? What's the max queue depth on the queue that message travels 
> through? Is it usually empty? 
We have noticed it on other queues, this one is the most easily tracked 
as it is the one only with human interaction.  This queue it is almost 
always empty.

On 06/09/2011 08:17 AM, Gordon Sim wrote:
>> The message is a JMS text message containing 9 characters, so fairly
>> small message. We have tried tuning the worker-threads thinking it was
>> an availability issue. This single message is more important than all
>> the other traffic our qpid is handling. Is there a way to give priority
>> to one queue over another? There is a large amount of traffic being
>> handled by the broker,
> What is your estimated peak total throughput? 
Roughly 9 million messages a day go through the broker.  Though roughly 
500k goes through during a 1 hour period 4 times a day.  The rest is 
fairly constant throughout the day.  So most hours have roughly 290k 
which probably 3/4 of that around 15 minutes before the hour to 15 after 
the hour.  And most these message are around 10k, some get as large as 
1meg though.

On 06/09/2011 08:17 AM, Gordon Sim wrote:
>> but not sure how the design is setup to handle
>> when they are many more sessions/queues than worker-threads. Does a
>> thread send all messages to a consumer before moving on to the next
>> queue? Or is the only way to ensure availability to further increase
>> worker-threads? I've had the threads as high as 100, but the load on the
>> system made the problem worse. Our setup is below.
>> We are using version 0.8 of the C broker and java client. The broker has
>> roughly 100 queues. Each queue has at least two consumers, 1 each from
>> separate servers in a cluster. We then also have 20 clients listens to 4
>> topics and 5 clients listening to 1 queue (the important one mentioned
>> above). So in general out broker has roughly 300 sessions open at any
>> given time.
> Is each session on its own connection? Or are connections shared? If 
> shared, how many connections are there? 
On the servers there is a connection/session pooling mechanism.  It 
ranges from dedicated session to connection, to no more than 5 sessions 
on a given connection.  In general a given consumer will always forward 
on to a specific producer so they are on the same session.  On the 
client there is only one connection for all 4 topic sessions as well as 
publishing to the queue that needs to be immediately processed.

At this point I'm considering standing up a second qpid instance.  The 
second instance would only handle high priority traffic so that it is 
not overloaded with all the other traffic.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message