Update ELASTIC_CTR.md

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能够较好处理并发请求，具有良好的扩展能力。