codis,redis,twemproxy三者对比

[hxfxjun]

环境：

%uname -a
Linux rh64.fanxj 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
%go version
go version go1.4.2 linux/amd64
%gcc --version
gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
Copyright © 2010 Free Software Foundation, Inc.
本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保；
包括没有适销性和某一专用目的下的适用性担保。

Tasks: 273 total, 1 running, 272 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.1%us, 0.2%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.2%us, 0.2%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1907932k total, 1704448k used, 203484k free, 4584k buffers
Swap: 4095992k total, 178968k used, 3917024k free, 94920k cached

test 65154 1 1 21:27 pts/4 00:00:52 ../bin/codis-config -c config.ini -L ./log/dashboard.log dashboard --addr=:18087 --http-log=./log/requests.log
test 65319 1 2 21:29 pts/5 00:02:14 ../bin/codis-server *:6381
test 65320 1 0 21:29 pts/5 00:00:21 ../bin/codis-server *:6382
test 72295 1 4 22:18 pts/6 00:01:32 ../bin/codis-proxy --log-level info -c config.ini -L ./log/proxy.log --cpu=8 --addr=0.0.0.0:19000 --http-addr=0.0.0.0:11000

测试命令：

redis-benchmark -t set -n 100000000 -P 500 -c 100 -r 1048576
redis-benchmark -t get -n 100000000 -P 500 -c 100 -r 1048576
redis-benchmark -t set -n 100000000 -c 100 -r 1048576
redis-benchmark -t get -n 100000000 -c 100 -r 1048576

测试1：100 client 未做CPU绑定

# 测试2：100 client 做CPU绑定，只允许codis-proxy用cpu 1

[yangzhe1991]

codis的版本是？

[spinlock]

有几个问题。

1. redis-benchmark -t get/set 的时候，实际上仅仅使用 key = "key:rand_int"，也就是说，这个压力测试实际上只使用了1台 redis。这种情况下 twemproxy & codis 有 redis 一半性能就已经足够好了。建议使用 -r 1048576 重新测试一下。
2. 目测 CPU 性能不行。只有 4 个 core ？压力测试的时候，redis 和 redis-benchmark 各占用一个 CPU，那么只剩下2个core给codis，但是 proxy 启动参数 --cpu=8，意味着 codis 会产生 8个 linux thread，增加 linux scheduling 开销。
3. cpu module name是什么，打开 turbo boost 了？比如我的工作机，Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz，压测单 redis 时，CPU 能到 3.9G，但是如果全部 cpu 都使用，主频最高能到 3.7G。所以单 redis 结果应该更好看。

建议找一个大一点的机器，重新测试一下。

PS1，建议指定一下默认 data 长度，因为默认情况下是 -d 2，即数据只有2个字节。应该没有人线上业务的数据只有2字节。所以 README.md 里用的是256。

PS2，对于 Pipeline=disabled 的情况，高并发不要使用 redis-benchmark，因为这种情况下 redis-benchmark 已经满了，不能压出更高的请求来，建议使用 memtierbenchmark，参见 bench2中第1、4两个图。第1张结果，redis benchmark 结果 twemproxy 和 codis 性能相近；但是第 4 张结果，codis 明显优于 twemproxy，因为 codis 是 multi-threaded 的。

[spinlock]

另外，两张图是一样的？是不是有一个图贴错了？

Codis2.0 的 Pipeline 性能远远好于 Codis1.9的，你可以分别对比一下。

[hxfxjun]

版本之前有误，现重新从github上取最新的进行测试（加上-r 1048576），结果已更新到原帖。
发现几个情总体
1.在未绑定cpu的情况下，codis的pipeline与redis的持平，在测试中codis-proxy的cpu在200%左右，
但在绑定cpu的情况下，codis的pipeline与twemproxy的持平
2.为什么set,get会比redis,twemproxy底(同时在绑定的情况下更底)

PS:这次测试的目的主要是在同一环境下做一个对比，所以对于机器性能好坏对每一个都是一样的

[spinlock]

我有两个疑问：

1. 为什么 taskset codis-proxy 之后，twemproxy 的性能会不一样？对 codis 的压测和 twemproxy 确定不是同时进行的么。
2. 为什么两个表都列出了 pipeline 的对比，但是标题分别写了 pipeline = disable 和 pipeline = 500？是不是错了。

"_这次测试的目的主要是在同一环境下做一个对比，所以对于机器性能好坏对每一个都是一样的_"

这句话我很不认同。我稍后给你解释，比较长。

[spinlock]

1. twemproxy 只有 redis 性能一半？
   • twemproxy 本质是 proxy，所以你的请求需要经过 client->proxy->redis->proxy->client 的过程，比直接访问 redis 多一倍通信。
   • twemproxy 是 C + epoll 实现的。twemproxy 设计过程中，对内存拷贝进行了优化，你可以去看 mbuf 数据结构的设计。他保证 twemproxy 内部不进行多余的复制操作。但是很复杂，完全没有想进行2次开发的欲望。
   • 所以高吞吐情况下，twemproxy 刚好是 redis 的一半。
2. 为什么 Codis 比 twemproxy 慢？
   • Codis 是 Go 开发的，底层 IO 本质也是通过 epoll 实现的。Go 为开发带来了方便，但是所有的便利都是以牺牲性能作为代价的。
     • Codis 追求简洁的实现，我们没有针对内存进行优化，所以会比 twemproxy 还要多一倍拷贝。
     • Go 虽然使用 epoll，但是 IO 都不是直接完成的，而是通过 IO thread，所以需要更多的线程间通信和线程切换。
     • 所以单 CPU 情况下， Codis 吞吐能到 twemproxy 的 1/2，redis 的 1/4，说明我的实现还是可以的。
3. 那需要 Codis 有什么用？
   • 如果你的业务需要 10G：没必要用 twemproxy 或者 Codis，影响心情，给自己添麻烦。
   • 如果你的业务需要 400G：你可以选择 单/多 twemproxy + 多 redis，毕竟在相同吞吐下，twemproxy 比 codis 有更好地 CPU 利用率。
   • 但是一旦你的业务需要迁移数据，比如机器上下线，容量调整，怎么办？
     • 单 twemproxy：方便调整，性能不行
     • 多 twemproxy：调整需要技巧，可能需要停止服，看具体业务需求，无论如何都很痛苦。
     • Codis？
       • 适当的 CPU 就可以获得比 twemproxy 更好的性能和可靠性，同时具备横向扩展的能力
       • 可动态调整。这一点就足够了。
       • 对 redis 集群而言，CPU 和 内存，哪个更贵？而且通常 redis 集群 CPU 都是空闲的。
4. 官方 cluster 呢？
   • 可以尝试+比较。性能肯定比 Codis 好。
   • 但是兼容性，以及数据迁移过程中数据可用性很糟糕。
5. Codis benchmark 应该测什么？
   • 多 CPU Codis vs 单 CPU twemproxy：
     • twemproxy 在不停止服务的情况下几乎没有横向扩展的能力
     • tewmproxy 多实例的情况下，这种伸缩的能力会更加糟糕
     • 这个测试的目的是告诉大家使用 Codis 的时候，不会比用 twemproxy 更糟糕，相反，提供几个 CPU 的话性能更好。
     • 此外，和 redis 峰值比较完全没有意义。愿意直接用 redis 的说明根本没有横向扩展的需求。
     • 把 Codis 限制在单 CPU 更没有意义。毕竟我们提供的所有 feature 都是有代价的。

[hxfxjun]

非常感谢你的详细解释，赞同第3点。