Evaluation of ZooKeeper
Let's evaluate ZooKeeper's design.
Throughput
In this lesson, we’ll evaluate the design of our Zookeeper. To keep it simple, we’ll discuss the throughput of read/write requests, load management, atomic broadcast, and system failure. However, before moving forward, let’s discuss the system’s requirements used for the evaluation.
Note: The experiment and results are taken from Hunt, Patrick, Mahadev Konar, Flavio P. Junqueira, and Benjamin Reed. “ZooKeeper: Wait-free Coordination for Internet-scale Systems.” In 2010 USENIX Annual Technical Conference (USENIX ATC 10). 2010.
System specification
For the evaluation of the system, the number of servers was changed, but the clients were always . Even though we have implemented the clients in both Java and C, we have used Java servers and asynchronous Java clients in the experiment. Each client has a minimum of requests for the server, where each request of either read or write will be done on the data of KB. Since the performance of all the requests, such as create()
, setData()
, getData()
, and many more, excluding sync()
is approximately the same, we won’t explicitly discuss these functions. To keep the session active, the client sends the count of completed operations after every , and we have recorded the status after every . To ensure that the server doesn’t get overwhelmed, we have added a throttle for requests which are concurrent requests, as shown in the table below.
Level up your interview prep. Join Educative to access 80+ hands-on prep courses.