Sending a persistent message from a producer to a consumer connected to the same broker can be extremely fast in activemq because of the concurrent store and forward default. The message persistence to disk with a sync write, with the sender must wait for, is carried out in parallel with the message dispatch to a waiting consumer. If the consumer is fast enough, it can respond with an ack *before* the original message send has hit disk and the disk write can be avoided along with the need to persist the ack.
When a network or brokers is involved, the network broker is typically a slow consumer. Because of store and forward, it cannot return till the message is stored on the other broker. The extra hop ensures that (in most cases) the brokers must persist the message twice, so you take the disk hit twice in terms of throughput. It is theoretically possible, that a network consumer could dispatch to a fast consumer on its target broker and it would ack quickly, allowing the network consumer to ack, before the original send hits the disk, but generally this won't occur because the disk write thread is eager to get on with its write task. So best case scenario in a network case is you take the hit of at least one disk sync. If you do not need absolute guarantees about message persistence, you could disable disk syncs on kahadb and enable async sends, this will greatly increase the through put lag as experienced by your clietnts. google 'activemq useAsyncSend' and 'kahadb enableJournalDiskSyncs' On 29 January 2012 15:06, tomerb <tom...@waze.com> wrote: > I have configured an ActiveMQ network of brokers, which seems to work fine, > function wise. > However, the capacity of messages traveling from a producer which is > connectes to broker a, to a consumer which is connected to broker b, is > about three times worse, then for producer/consumer connected to the same > broker. > This seems odd to me, as I was under the impression that once broker a, > passes the message to broker b, it is a delivered message (from broker a > POV), so there should be no capacity decrease. > > here is my activemq.xml configuration: > > <beans > xmlns="http://www.springframework.org/schema/beans"; > xmlns:amq="http://activemq.apache.org/schema/core"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd > http://activemq.apache.org/schema/core > http://activemq.apache.org/schema/core/activemq-core.xsd";> > > <broker xmlns="http://activemq.apache.org/schema/core"; > brokerName="localhost" dataDirectory="${activemq.base}/data" > destroyApplicationContextOnStop="true" persistent="false"> > > <destinationPolicy> > <policyMap> > <policyEntries> > <policyEntry topic=">" producerFlowControl="true" > memoryLimit="5mb"> > <pendingSubscriberPolicy> > <vmCursor /> > </pendingSubscriberPolicy> > </policyEntry> > <policyEntry queue=">" producerFlowControl="true" > memoryLimit="50mb"> > > > </policyEntry> > </policyEntries> > </policyMap> > </destinationPolicy> > > > > > > > <managementContext> > <managementContext createConnector="false"/> > </managementContext> > > <networkConnectors> > <networkConnector name="tomer-amq-test1" > uri="static:(tcp://tomer-amq-test1:61616)" networkTTL="3"/> > </networkConnectors> > > > > <persistenceAdapter> > <kahaDB directory="${activemq.base}/data/kahadb"/> > </persistenceAdapter> > > > > > > > <transportConnectors> > <transportConnector name="tomer-amq-test2" > uri="tcp://0.0.0.0:61616"/> > </transportConnectors> > > </broker> > > > <import resource="jetty.xml"/> > > </beans> > > > Am I wrong? > Is there some special configuration I have to employ? > can someone shed some light on the flow? > > Tx Tomer > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/network-of-brokers-reduced-capacity-tp4338401p4338401.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. -- http://fusesource.com http://blog.garytully.com
