Update ELASTIC_CTR.md

doc/ELASTIC_CTR.md

@@ -429,10 +429,11 @@ $ ./get_values -h 192.168.1.1 -t 3 -r 10000 -b 1000
 32 | 1000 | 17256 | 1854
 
 
-###测试结论
+### 测试结论
 
 由于Redis高效的时间驱动模型和全内存操作，在单并发时，redis平均响应时间与cube相差不多% (1643us vs. 1312us)
 
 在扩展性方面，redis受制于单线程模型，随并发数增加，响应时间加倍增加，而总吞吐在1000qps左右即不再上涨；而cube则随着压测并发数增加，总的qps一直上涨，说明cube能够较好处理并发请求，具有良好的扩展能力。
 
+RocksDB在线程数较少的时候，平均响应时间和qps慢于Redis，但是在16以及更多线程的测试当中，RocksDB提供了更快的响应时间和更大的qps。