From 21ff2902a248aad26d90e4761e76ef4ea9dd7879 Mon Sep 17 00:00:00 2001
From: Wang Guibao <wang_guibao@163.com>
Date: Tue, 15 Oct 2019 17:01:50 +0800
Subject: [PATCH] Update ELASTIC_CTR.md

---
 doc/ELASTIC_CTR.md | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/doc/ELASTIC_CTR.md b/doc/ELASTIC_CTR.md
index aae03550..3fa6fd62 100755
--- a/doc/ELASTIC_CTR.md
+++ b/doc/ELASTIC_CTR.md
@@ -370,12 +370,14 @@ client端和server端分别位于2台独立的云主机，机器间ping延时为
 
 基本原理，启动k个线程，每个线程访问M次cube server，每次批量获取N个key，总时间加和求平均。
 
-并发数 (压测线程数) | batch size | 平均响应时间 (us)
--------|------------|-----------
-1 | 1000 | 1680
-2 | 1000 | 1690
-3 | 1000 | 1675
-4 | 1000 | 1680
+并发数 （压测线程数） | batch size | 平均响应时间 (us) | total qps
+-------|------------|-------------|---------------------------
+1	| 1000 | 1312 | 762
+4	| 1000 | 1496 | 2674
+8	| 1000 | 1585 | 5047
+16 | 1000 | 1866 | 8574
+24 | 1000 | 2236 | 10733
+32 | 1000 | 2602 | 12298
 
 ### Redis测试环境
 
@@ -412,6 +414,6 @@ $ ./get_values -h 192.168.1.1 -t 3 -r 10000 -b 1000
 
 由于Redis高效的时间驱动模型和全内存操作，在单并发时，redis平均响应时间比cube少接近50% (1100us vs. 1680us)
 
-在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加，而总吞吐在1000qps左右即不再上涨；而cube则由于多线程吞吐具有优异的线性扩展能力，总的qps随着线程数增加基本线性上涨。
+在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加，而总吞吐在1000qps左右即不再上涨；而cube则随着压测并发数增加，总的qps一直上涨，说明cube能够较好处理并发请求，具有良好的扩展能力。
 
 
-- 
GitLab