Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
Sender: tbain98@gmail.com
In-Reply-To: <1445438152801-4703233.post@n4.nabble.com>
References: <1445433386073-4703223.post@n4.nabble.com>
	<CAPVVMa-FDsK_d6r-kqnyH1Mn=bDb+bshzHHcMtP9=KFNesU_1Q@mail.gmail.com>
	<1445435978116-4703230.post@n4.nabble.com>
	<CAPVVMa-AYi+otBJLDMZvOabY3vRWozL3sybsKehQcE-ufzDs1w@mail.gmail.com>
	<1445438152801-4703233.post@n4.nabble.com>
Date: Thu, 22 Oct 2015 07:35:48 -0600
Message-ID: 
 <CAPVVMa95PHqjven0BbCq94BOc=_fUn7m-N=TqJE1ngq3Q20P0w@mail.gmail.com>
Subject: Re: Slow MySQL datastore performance.
From: Tim Bain <tbain@alumni.duke.edu>
To: ActiveMQ Users <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary=089e013c65d6b097600522b192bf

--089e013c65d6b097600522b192bf
Content-Type: text/plain; charset=UTF-8

In your example of 100 consumers, I would expect that when a message is
received 100 ack rows would be inserted (ideally in a single transaction),
and when each consumer receives its copy of the message one row would be
updated (so when they all have finally received it, you'll have done 100
updates).  I'm assuming this all makes sense and your question is "why is
each update a separate transaction?"

Batching updates made within a very short time window into a single
transaction is possible, but 1) it's more complicated code because you need
to coordinate the requested updates across threads, and 2) you increase
latency for some threads because the early ones in the window have to wait
till the window closes and the database update is issued before taking
their next action (which may depend on the knowledge that the previous ack
has been durably recorded), which might be worse than the overhead of
starting a transaction.

Any solution that wanted to batch several updates from the same thread
(i.e. allow the thread to continue working asynchronously) would have to
ensure that the actions taken thereafter would not be invalid if the broker
crashed without writing them to the database (which I think would be
difficult) or would need to relax the guarantees that ActiveMQ makes about
how messages are handled (probably not going to happen just to improve
performance of a store technology that's infrequently used).
On Oct 21, 2015 8:47 AM, "will1" <will1@me.com> wrote:

> Thanks Tim.. If anyone has any relevant benchmarks they could provide, that
> would be really useful.. any more thoughts on the original question would
> be
> appreciated also..
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Slow-MySQL-datastore-performance-tp4703223p4703233.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

--089e013c65d6b097600522b192bf--