You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Torsten Mielke (JIRA)" <ji...@apache.org> on 2012/07/17 11:56:35 UTC
[jira] [Commented] (AMQ-3557) Performance of consumption with JDBC
persistance and Microsoft SQL Server
[ https://issues.apache.org/jira/browse/AMQ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416048#comment-13416048 ]
Torsten Mielke commented on AMQ-3557:
-------------------------------------
There was recently an improvement made to the JDBC persistence adapter to remove an unneeded synchronization point. See the last comment of AMQ-2868. This fix improves performance of the JDBC persistence adapter in case of using multiple consumers.
> Performance of consumption with JDBC persistance and Microsoft SQL Server
> -------------------------------------------------------------------------
>
> Key: AMQ-3557
> URL: https://issues.apache.org/jira/browse/AMQ-3557
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira