Hello, Q: Does anyone know of a practical limit to the number of Topics a broker should be expected to handle?
In Gary Tully's advise for http://activemq.apache.org/javalangoutofmemory.html avoiding out of memory exceptions he mentions some implications of having a high number of destinations: "...If there are large numbers of Destinations there will be a large number of threads and their associated memory resource usage." There will also be kernel and TCP buffer implications as we spin up the number of producers and consumers. To give some rough guidelines for my scenario (per broker): - 256 Topics - 32/64 Producers - 64/128 Consumers (non-durable) - 2k/4k messages - 250/500 msg/sec - Lower latency is better - Quad core host with 4GB RAM (64bit linux distro) - Reasonably peppy network Producers and consumers will maintain long-lived sessions, so the broker should primarily be busy forwarding messages and general maintenance (i.e. connections, threads, cluster communications...). I expect more factors to arise from the solution(s) used for providing high availability and scalability. Recent discussions regarding potential scalability issues with using a network of brokers (NOB) has me thinking I will (initially at least) use broker clusters and custom routing logic to locate the proper broker pair. I don't expect to have more than 32 brokers, but I want to avoid paying a high cost for cluster synchronization. Q: With the numbers I listed above, should I start with the network of brokers approach? If not, which of the values would I need to adjust to make NOB a workable solution? Thanks, Erik -- View this message in context: http://www.nabble.com/Practical-limit-to-number-of-topics-per-broker--tp19484576p19484576.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
