From e46897e3f40139371b25d66c4984f3aa140153a1 Mon Sep 17 00:00:00 2001 From: toby lorne Date: Mon, 21 Oct 2024 18:34:47 +0200 Subject: [PATCH] sites/www.toby.codes: fix use of ZK/ZooKeeper Signed-off-by: toby lorne --- sites/www.toby.codes/posts/2024-10-ZooKeeper-and-quorum.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sites/www.toby.codes/posts/2024-10-ZooKeeper-and-quorum.md b/sites/www.toby.codes/posts/2024-10-ZooKeeper-and-quorum.md index 6fc46df..b9cbc3d 100644 --- a/sites/www.toby.codes/posts/2024-10-ZooKeeper-and-quorum.md +++ b/sites/www.toby.codes/posts/2024-10-ZooKeeper-and-quorum.md @@ -35,9 +35,10 @@ would not be possible because latency would be too high (eg Australia/NZ). We scale out the capacity to serve many reads by using [ZooKeeper observers](https://zookeeper.apache.org/doc/r3.8.3/zookeeperObservers.html) as we found that we saw degraded performance with more than 10k (see below, -2022) connections per ZK node. Using observers has allowed us to get better -write performance, because clients connect to the observers and ZK primaries -deal only with leader election, writes, and traffic from the observers. +2022) connections per ZooKeeper node. Using observers has allowed us to get +better write performance, because clients connect to the observers and +primaries deal only with leader election, writes, and traffic from the +observers. With less than 30 ZooKeeper servers (not all primaries), we are able to handle multiple hundreds of thousands of simultaneous connections, split across >3