应用内部缓存与redis缓存 测试

前置

mongodb查询结果缓存起来
缓存 expire 时间 10s
/search/user?wd=yoso查询将会遍历 users 集合，因为是模糊查询的原因，无法使用索引优化。
一个优化方式则是，将 users 集合分片。这样可能会快 n-1(n为分片数量) 倍（实际上是不可能的，因为还有网络延迟）

测试命令

hey -n 50000 https://localhost/v2/search/user?wd=yoso

1. 不用缓存，每次都从mongodb查询

Summary:
  Total:        62.0872 secs
  Slowest:      0.7800 secs
  Fastest:      0.0011 secs
  Average:      0.0608 secs
  Requests/sec: 805.3188

2. 使用redis做缓存，复用 http 连接

Summary:
  Total:        10.0835 secs
  Slowest:      0.5076 secs
  Fastest:      0.0003 secs
  Average:      0.0098 secs
  Requests/sec: 4958.5893

3. 应用内部做缓存，复用 http 连接

Summary:
  Total:        4.3951 secs
  Slowest:      0.1666 secs
  Fastest:      0.0003 secs
  Average:      0.0043 secs
  Requests/sec: 11376.3111

测试命令加上 -disable-keepalive 标志，关闭连接复用

4. 使用redis做缓存，每次使用新的 http 连接

Summary:
  Total:        16.1351 secs
  Slowest:      0.0787 secs
  Fastest:      0.0023 secs
  Average:      0.0267 secs
  Requests/sec: 1859.2994

5. 应用内部做缓存，每次使用新的 http 连接

Summary:
  Total:        15.5900 secs
  Slowest:      0.4916 secs
  Fastest:      0.0022 secs
  Average:      0.0258 secs
  Requests/sec: 1924.3128

总结

1. 应用内部做缓存速度很快，但是不能水平拓展，受到单机计算能力，内存大小的限制。并且缓存无法管理。
2. redis做缓存慢大约一倍(web服务器和redis在统一主机上，实际环境中影响最大的是网络)。但是redis有良好的拓展性，可以有redis集群，水平拓展。有相关配套的工具来管理redis。
3. 从4，5可以看出，在关闭连接复用后，应用内缓存QPS大幅度下降80%以上，而redis缓存则下降60%左右。最终二者的QPS相差无几。因此可以得出结论：建立连接消耗了大量的时间。在web服务的实际环境中应用内缓存和redis缓存是差不多的，最大的敌人则是网络时延。
4. 对于个人开发者而言，没有那么多的资金购买多个服务器，且访问量也很小，采用应用内缓存能够最大程度上利用单机的资源。（不过又说回来了，既然访问量很小，用redis也没啥问题。。。）

---

后记

一般来说最便宜的服务器的配置如下：

• 1Mb的带宽
• 1 CPU
• 1GB内存
• 50GB硬盘

对于web服务器而言，最大的约束大概是 1Mb的带宽。
1Mb = 128KB，假设一个响应的大小为1KB，那么 QPS 也就128。那在本机上测试的QPS达到10000都没用。