activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislaw Kogut <sko...@sistyma.net>
Subject ActiveMQ consumer performance and scalability
Date Wed, 15 Dec 2010 14:41:31 GMT
Hello.

I'm currently evaluating ActiveMQ as a message broker for our service. We
need scalable, transacted, low-latency message broker, but ActiveMQ shows
not very good results to me.

Config: ActiveMQ 5.4.2 with nio:// transport, KahaDB persistence adapter and
data directory on tmpfs filesystem (to get rid of disk performance impact).

In details: With persistence enabled and commiting every message sent to
broker we have about 2k messages/s on producer side, and similar consuming
speed with one producing thread.
It also has good latency - about 5 milliseconds to deliver message, but 2k
msg/s can be slow in future, so I'm trying to commit messages after some
count of them sent, for example after every 100 messages. This shows better
throughput, about 10k messages/s, but now consumer side looks slow. Also,
latency is increased because time to fill this "100 messages" cap.

Also, consumer side is not able to consume all these messages on this rate
and queue length grows.

It is very possible also, I will have more than one producer for one queue
because of application design. I also test this scenario and producers are
relatively fast, but consumer become very slow, receiving 1-2 messages per
second. With enabled producer flow-control broker can stop producers and
serve consumer better, but it has very bad impact on latency as producer
should wait for broker to acknowledge messages, preventing new data from
being sent.


Is there is a way to consume messages from queue faster? I'm tried both
implementing MessageListener and MessageConsumer.receive(), but both show
same result. Usage of vmCursor or prefetching in broker makes no changes to
situation.

Also, is there any topology for distirbuting one ActiveMQ queue to more than
one machine without big latency impact to increase it's throughput?

-- 
Regards,
Stanislaw Kogut
Sistyma LLC

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message