From fac01665e2b11ecffda39401074db57d43b8f967 Mon Sep 17 00:00:00 2001 From: Jiawei Wang Date: Thu, 24 Oct 2019 11:35:54 +0800 Subject: [PATCH] Update ELASTIC_CTR.md --- doc/ELASTIC_CTR.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/ELASTIC_CTR.md b/doc/ELASTIC_CTR.md index 9aa4c974..fc9dfef7 100755 --- a/doc/ELASTIC_CTR.md +++ b/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。 -- GitLab