Well apparently something is alleviated, but I'm trying to understand
what... The 2 queues are sequential, and the 1st queue is almost always
empty, so I cannot see why I have a bigger buffer.
On Sat, Aug 4, 2012 at 1:17 PM, Sam (Stephen Samuel)
wrote:
> With the intermediate queue you have a bi
With the intermediate queue you have a bigger buffer, a 2nd queue.
There might be a bottleneck on certain calls from your initial
endpoint which having the 2nd queue alleviates.
On Sat, Aug 4, 2012 at 9:48 AM, Xenofon Papadopoulos
wrote:
> Thanks for the tips. I'm trying, however, to understand w
Thanks for the tips. I'm trying, however, to understand why there is better
behavior with the intermediate queue, given that all other parameters
(threads etc) remain the same.
Also this is a test; in production we normally use about 800 concurrent
consumers, and the resource use in the servers is
tough to say given the unknowns about your setup, but here are a couple of
things to consider...
-for kahadb, set enableJournalDiskSyncs to false to get much better
throughput
-try fewer consumer threads...100 is a lot and you generally have
diminished/negative results with larger thread counts
-t
Sorry in advance if I should have posted that in ActiveMQ list, but here is
our case.
We are running the same test with two different setups:
Setup 1:
We are using a single ActiveMQ broker and a single Camel with the routes:
from( "jetty://http://..."; ).inOnly( "activemq:queue:queue
