maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

On 2013-11-18 03:22, Pavel Ivanov wrote:
> It looks like during the conversation both of us have got completely
> confused with terminology and talked about different meanings of
> performance in different places. So let me try to bring that to a more
> sensible description. To be short I'll consider only three different
> aspects of performance:
>
> 1. Maximum steady rate of completely independent transactions measured
> long after the beginning of testing. For semi-sync this is limited to
> 1 per RTT to the closest node. The safe limit (the one when farthest
> nodes won't fall behind in replication) could be lower, but it depends
> mostly on network throughput to the farthest node (not on RTT). I
> don't know what are limiting factors in Galera for this situation, but
> I'm sure that with the right implementation of inter-node
> communication Galera can outperform semi-sync by a big margin here.
>
> 2. Maximum steady rate of dependent transactions (e.g. updates to a
> single row) measured long after the beginning of testing. For
> semi-sync this is the same as for previous one -- limited to 1 per RTT
> to the closest node. For Galera this is limited to 1 per RTT to the
> farthest node, so definitely worse than with semi-sync.
>
> 3. Sudden burst of parallel dependent transactions, i.e. what maximum
> number of updates to a single row can one perform in parallel in say
> 15 seconds (probably from hundreds of connections) if he didn't
> perform any transactions before that and won't perform any
> transactions after those 15 seconds. For semi-sync with
> rpl_semi_sync_master_wait_point = AFTER_COMMIT this is limited only to
> performance of a single node as if there was no replication at all
> (just writing of binlogs). For semi-sync with
> rpl_semi_sync_master_wait_point = AFTER_SYNC this is still limited to
> 1 per RTT to the closest node. For Galera this is still limited to 1
> per RTT to the farthest node.

Many thanks! That clears it.

Regards,
Alex

> So anyone who's reading this can make his own conclusions what
> tradeoffs he prefers to make for his production systems.
>
>
> Pavel

--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011