On 15 Oct 2008, at 00:16, lawrencek wrote:
Hi,
I'm designing a system that will have a few central services and
upward of
6000 processes on thousands of machines on a LAN. They all
communicate using
ActiveMQ, with the central services having well-known queue names
and the
distributed components having randomly-generated queue names. I
recently
profiled the broker and found that every queue results in four
threads (one
for the queue, one for checkpoint (?), and two for each of two related
topics (consumer and producer)). Additionally, every connection to the
broker results in two threads (dispatcher and transport). That means
that
each of the 6000 distributed components will result in six threads, or
36,000 threads total in the broker. I don't know whether using a
network of
brokers will allow me to reduce this to a reasonable number per
process. I
also have to worry about the 6000 TCP connections to the broker,
which could
also presumably be distributed across a network of brokers.
More generally, though, I'm concerned that ActiveMQ, and really JMS,
was
never intended to support this many clients. Perhaps I should use
JMS only
for communication amongst the central services, and all communication
to/from the distributed services should use a simpler RPC scheme.
Does anyone know if ActiveMQ can handle this many clients? What's
the most
number of clients anyone has seen on ActiveMQ or JMS?
Thanks,
Lawrence
--
View this message in context:
http://www.nabble.com/6000-ActiveMQ-clients-tp19983973p19983973.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Hi Lawrence,
ActiveMQ - with some tuning - should be able to handle this load. I'd
recommend looking at using partioning your system (traffic splitting)
with networks of brokers anyway - but to reduce the number of threads
in use do the following:
1. reduce number of threads for connections in the broker use NIO -
see http://activemq.apache.org/configuring-transports.html
2. Use optimizeDispatch in the Queues - see
http://activemq.apache.org/per-destination-policies.html
cheers,
Rob
Rob Davies
http://fusesource.com
http://rajdavies.blogspot.com/
