Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change 
notification.

The "ZooKeeper/ServiceLatencyOverview" page has been changed by PatrickHunt.
http://wiki.apache.org/hadoop/ZooKeeper/ServiceLatencyOverview?action=diff&rev1=22&rev2=23

--------------------------------------------------

  
  == Result Summary ==
  
+ In the following tests we are varying the number of cores and clients 
workloads. The clients are homogeneous, each is performing 110,000 asynchronous 
operations against the service, where the workload is:
- In the following two graphs you can see the results of this experiment. The X 
axis shows the number of operations per second that were processed by the 
server for 1, 2 & 4 cores, where 1, 10 & 20 clients were testing the cluster.
- 
- ||'''Standalone Server'''||'''Ensemble with 3 Serving Nodes'''||
- ||{{attachment:standalone_perf.png|Standalone 
Server}}||{{attachment:ensemble_3_perf.png|Ensemble with 3 serving nodes}}||
- 
- Each client is performing 110,000 asynchronous operations against the 
service, where the workload is:
   * create 10k permanent znodes of size 100 bytes
   * set 10k znodes of size 100 bytes
   * get 10k znodes (100 bytes returned)
@@ -73, +68 @@

  
  === Standalone Result ===
  
+ In the following graph you can see the results of this experiment for a 
single Standalone serving instance. The X axis shows the number of operations 
per second that were processed by the server for 1, 2 & 4 cores, where 1, 10 & 
20 clients were testing the cluster.
+ 
+ ||'''Standalone Server'''||
+ ||{{attachment:standalone_perf.png|Standalone Server}}||
+ 
+ 
  From the graph and the data below we can see that moving from a workload of 1 
to 10 clients shows an increase in overall operations performed by the server. 
However moving from 10 to 20 clients we see no further increase (rather some 
decrease, potentially due to the overhead of selector processing and connection 
management in the server networking code). Increasing the number of cores 
provides modest increase in the overall output of the server. This makes sense 
as there are a limited number of threads running in a standalone server, it is 
unable to take advantage of the additional cores.
  
  === Ensemble with 3 Serving Nodes Result ===
+ 
+ In the following graph you can see the results of this experiment for a 3 
Server Ensemble. The X axis shows the number of operations per second that were 
processed by the server for 1, 2 & 4 cores, where 1, 10 & 20 clients were 
testing the cluster.
+ 
+ ||'''Ensemble with 3 Serving Nodes'''||
+ ||{{attachment:ensemble_3_perf.png|Ensemble with 3 serving nodes}}||
  
  Here we see distinct increase in the output of the cluster as we move the 
workload from 1 to 10 to 20 clients. There is some additional headroom that we 
could see if we were to test with higher workloads. Additionally as the core 
count increases we see output gains there as well. Ensemble servers are running 
additional threads to process the quorum communication, these threads are 
taking advantage of the additional parallelism.
  

Reply via email to