![](https://secure.gravatar.com/avatar/e116f298afc14b2ee30632c823110d84.jpg?s=120&d=mm&r=g)
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