activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From spiiff <>
Subject performance of the different amq persistence solutions
Date Thu, 24 Apr 2008 12:18:40 GMT

we have a performance problem with ActiveMQ 5.0.0.
I wrote a simple Java application that stores 5000 small object messages
into a queue. 
At the same time a callback is listening on the queue and consuming the
My message broker/activeMQ is started standalone, my clients are connected
by TCP: 

ConnectionFactory connectionFactory =
			new ActiveMQConnectionFactory("tcp://localhost:61616");
I run this test case with the different persistence mechanisms that ActiveMQ
And I meausure the time from the first producer.send() until all 5000
messages have arrived in the callback.
This tests are driven on a Windows XP machine. And our two consumer/producer
sessions are set to Session.AUTO_ACKNOWLEDGE. 

-No persistence: 1610 ms   (~ 1,6 sec)
	This is no option for us, we need reliable messaging and persistence.

-KAHA-Persistence/amqPersistenceAdapter:  282114 ms  (~ 282 sec)
	This is a complete new approach? Or is it a further development of the
Journal(based on Howl)?
	Is there more information about this solution then on this website: ?
	Because this could be really an option for us, but we have no idea how
robust this code is.
	Our whole businesslogic communication is based on JMS

-High Performance Journal mit Derby DB: 534396 ms  (~ 534 sec)
	Derby is no option for us.
-JDBC Persistence (Oracle) without Journaling : 767598 ms  (~ 768 sec)
-High Performance Journal mit Oracle DB:  1035774 ms  (~1036 sec)
	The journal is being synced into the database.
	I found no description when this action takes place. We guess after some
hard coded period.
	When I look at the database tables there is a big fluctuation during my
test run.
	It seems that every message is written into the DB and then dropped again.
	We expected that when we consume the messages very fast they will not be
synced into the database, because they are consumed before the checkpoint.
	Has anybody experience with this? Is this configurable?
	Because this seems to slow down the "High Performance Journal with long
term persistence storage" solution.

Of course the message broker is stressed when a lot of messages are written
and consumed at the same time. 
When I first write all 5000 messages and then afterwards open the callback
every solution is very fast...

maybe someone has experience with the checkpointing from journal to long
term persistence..

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message