Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 611907

Summary: Browse mode performance in a queue degrades as queue gets larger
Product: Red Hat Enterprise MRG Reporter: Mike Cressman <mcressma>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED ERRATA QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 1.2CC: jneedle, ppecka
Target Milestone: 1.2.2   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
C: reading messages from a queue sequentially without taking them off the queue (browse mode) C: performance scales poorly as the size of the queue grows F: change the algorithm for traversing through the messages R: the next message is found more quickly, even for large queues
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-08 01:50:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike Cressman 2010-07-06 20:16:39 UTC
Description of problem:
Browsing messages in a queue slows down exponentially as the number of messages in the queue increases, while maxing out the CPU available.


Version-Release number of selected component (if applicable):
MRG Messaging 1.2

How reproducible:
Every time

Steps to Reproduce:
1. Create a queue
2. Add a number of messages to the queue (say, 25,000)
3. Read them off the queue in browse mode (ACQUIRE_MODE_NOT_ACQUIRED), i.e. read the messages off the queue but do not acknowledge them (leave them on the queue).  Note the time that it takes.
4. Double the number of messages on the queue (to 50,000)
5. Again, read them in browse mode.
  
Actual results:
It takes about 4 times as long to read twice as many messages.  This ratio continues if the queue is made even larger.

Expected results:
Performance degradation should be closer to linear.

Additional info:

Comment 2 Mike Cressman 2010-09-24 15:15:00 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
C: reading messages from a queue sequentially without taking them off the queue (browse mode)
C: performance scales poorly as the size of the queue grows
F: change the algorithm for traversing through the messages
R: the next message is found more quickly, even for large queues

Comment 6 errata-xmlrpc 2010-10-08 01:50:06 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0756.html