activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Rahn (Updated) (JIRA)" <>
Subject [jira] [Updated] (AMQ-3557) Performance of consumption with JDBC persistance and Microsoft SQL Server
Date Fri, 21 Oct 2011 12:54:32 GMT


Nicholas Rahn updated AMQ-3557:

    Attachment: activemq.xml

Configuration file we are using.
> Performance of consumption with JDBC persistance and Microsoft SQL Server
> -------------------------------------------------------------------------
>                 Key: AMQ-3557
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Message Store, Performance Test
>    Affects Versions: 5.4.3, 5.5.0, 5.5.1
>         Environment: Microsoft SQL Server 2005, Debian Linux, 
>            Reporter: Nicholas Rahn
>              Labels: jdbc, performance, sqlserver
>         Attachments: activemq.xml
> We are trying to upgrade our ActiveMQ installation and have run into some performance
issues. I'll attached our activemq.xml file to this bug.
> I've setup a fresh SQLServer database for our upgrade tests and using the example Ant
tools in the distribution, I've populated a persistent queue with 1,000,000 messages. I then
consume those messages using the example Ant consumption script. The producing side works
fine. However the performance of the consumption side is extremely poor. To consume just 10,000
of those messages takes over 5 minutes.
> The consumer will pause for 4-5 seconds every 200 messages. This is easily visible in
the output of the Ant script. We have also traced the DB to see what is happening there and
have found that the findNextMessagesStatement takes 4-5 seconds every time it is executed.
The statement's ID parameter is increased by 200 every time it is executed.  We also noticed
the use of the "SET ROWCOUNT 10000" statement setting the maximum number of rows returned
from a query at 10000. We also traced previous versions of ActiveMQ and found that SET ROWCOUNT
was used much more often, with much smaller values (often 10, 20 or 30).
> We have also tested the same setup with version 5.4.0 and did not have the same issues.
Consumption speeds with 5.4.0 were normal, with no pauses. Version 5.4.3 did have the problem,
however. So there seems to be a regression somewhere between 5.4.0 and 5.4.3 (also affects
5.5.0 and later).
> Please let me know if you need more information, including the database traces.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message