twemproxyのベンチマークを測定してみました
追記
Twitterで計測方法について@bulkneetsさんからフィードバックいただきました。 ありがとうございます。
@t_mitz それだとクライアントライブラリ側の微妙な性能差しかベンチに反映されないですよ、 see http://t.co/fVKcUPPqIV
— mala (@bulkneets) October 5, 2013
@t_mitz wallclockが実時間ですね、そして一台でやると差が出過ぎて比較には不適切かと。リモートサーバーでやるとクライアント側のCPU時間が殆ど変わらず(もしくはコネクションまとまった分小さく) 実時間がproxyする分20%程度劣化、になると思います
— mala (@bulkneets) October 5, 2013
今出してるベンチの数値はCPU使用時間のベンチになっているため、プロセス間通信は反映されていないためご注意ください。 今度はリモートサーバー環境でBenchmark.pm使わずに試してみたいと思います。
元記事
twemproxyのベンチマークを測ってみました。100000回 set/getをするだけのベンチです。
ベンチマークスクリプト (perl)
ベンチ結果
Benchmark: timing 100000 iterations of memcached, redis, redis_pipelining, twemproxy_memd, twemproxy_redis... memcached: 8 wallclock secs ( 0.85 usr + 2.39 sys = 3.24 CPU) @ 30864.20/s (n=100000) redis: 13 wallclock secs ( 6.18 usr + 3.04 sys = 9.22 CPU) @ 10845.99/s (n=100000) redis_pipelining: 9 wallclock secs ( 4.31 usr + 2.24 sys = 6.55 CPU) @ 15267.18/s (n=100000) twemproxy_memd: 16 wallclock secs ( 0.98 usr + 2.81 sys = 3.79 CPU) @ 26385.22/s (n=100000) twemproxy_redis: 22 wallclock secs ( 6.86 usr + 3.32 sys = 10.18 CPU) @ 9823.18/s (n=100000) perl twemproxy_benchmark.pl 28.26s user 196.37s system 79% cpu 4:42.90 total
まとめ
- twemproxyを挟むと直接接続するときと比べて約20%ほど性能は落ちる
- 複数台のmemdを管理するコストが無くなるメリットと比べると大した速度低下ではない気はする
- redisはpipelining使う方がやっぱり速い