Update ELASTIC_CTR.md

doc/ELASTIC_CTR.md

@@ -390,7 +390,7 @@ client端为基于[redisplusplus](https://github.com/sewenew/redis-plus-plus)编
 调用方法：
 
 ```bash
-$ ./get_values -h 192.168.48.25 -t 3 -r 10000 -b 1000
+$ ./get_values -h 192.168.1.1 -t 3 -r 10000 -b 1000
 ```
 
 其中
@@ -399,17 +399,19 @@ $ ./get_values -h 192.168.48.25 -t 3 -r 10000 -b 1000
 \-r 每线程请求次数
 \-b 每个mget请求的key个数
 
-并发数 （压测线程数） | batch size | 平均响应时间 (us)
--------|------------|-----------
-1 | 1000 | 1100
-2 | 1000 | 2110
-3 | 1000 | 3050
-4 | 1000 | 4100
+并发数 （压测线程数） | batch size | 平均响应时间 (us) | total qps
+-------|------------|-------------|---------------------------
+1  | 1000 | 1159 | 862
+4  | 1000 | 925  | 1079
+8  | 1000 | 931  | 1073
+16 | 1000 | 996  | 1034
+24 | 1000 | 995  | 1004 
+32 | 1000 | 1003 | 996
 
 ###测试结论
 
 由于Redis高效的时间驱动模型和全内存操作，在单并发时，redis平均响应时间比cube少接近50% (1100us vs. 1680us)
 
-在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加；而cube则平均响应时间基本保持不变，说明cube多线程吞吐具有优异的线性扩展能力。
+在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加，而总吞吐在1000qps左右即不再上涨；而cube则由于多线程吞吐具有优异的线性扩展能力，总的qps随着线程数增加基本线性上涨。