Update ELASTIC_CTR.md

doc/ELASTIC_CTR.md

@@ -370,9 +370,7 @@ client端和server端分别位于1台独立的云主机，机器间ping延时为
 
 基本原理，启动k个线程，每个线程访问M次cube server，每次批量获取N个key，总时间加和求平均。
 
-测试结论：
-
-线程数 | batch size | 平均响应时间 (us)
+并发数 (压测线程数) | batch size | 平均响应时间 (us)
 -------|------------|-----------
 1 | 1000 | 1680
 2 | 1000 | 1690
@@ -405,9 +403,17 @@ $ ./get_values -h 192.168.48.25 -t 3 -r 10000 -b 1300
 \-r 每线程请求次数
 \-b 每个mget请求的key个数
 
-线程数 | batch size | 平均响应时间 (us)
+并发数 （压测线程数） | batch size | 平均响应时间 (us)
 -------|------------|-----------
 1 | 1000 | 1100
 2 | 1000 | 2110
 3 | 1000 | 3050
 4 | 1000 | 4100
+
+###测试结论
+
+由于Redis高效的时间驱动模型和全内存操作，在单并发时，redis平均响应时间比cube少接近50% (1100us vs. 1680us)
+
+在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加；而cube则平均响应时间基本保持不变，说明cube多线程吞吐具有优异的线性扩展能力。
+
+