我正在尝试使用Redis和Twemproxy测试一个非常简单的设置,但我找不到一种方法来加快它的速度。
我有2台redis服务器,我使用最低配置运行:
./redis-server --port 6370
./redis-server --port 6371
从源代码编译并在1台机器下运行所有适当的内存和CPU。
如果我在其中一个实例中运行redis-benchmark,我会得到以下结果:
./redis-benchmark --csv -q -p 6371 -t set,get,incr,lpush,lpop,sadd,spop -r 100000000
"SET","161290.33"
"GET","176366.86"
"INCR","170940.17"
"LPUSH","178571.42"
"LPOP","168350.17"
"SADD","176991.16"
"SPOP","168918.92"
现在我想在两个实例前面使用Twemproxy来分发请求并获得更高的吞吐量(至少这是我的预期!)。
我对Twemproxy使用了以下配置:
my_cluster:
listen: 127.0.0.1:6379
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: false
redis: true
servers:
- 127.0.0.1:6371:1 server1
- 127.0.0.1:6372:1 server2
我把胡桃夹子当作:
./nutcracker -c twemproxy_redis.yml -i 5
结果非常令人失望:
./redis-benchmark -r 1000000 --csv -q -p 6379 -t set,get,incr,lpush,lpop,sadd,spop-q -p 6379
"SET","112485.94"
"GET","113895.21"
"INCR","110987.79"
"LPUSH","145560.41"
"LPOP","149700.61"
"SADD","122100.12"
我试图通过获取Twemproxy的统计数据来了解正在发生的事情:
telnet 127.0.0.1 22222
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
{
"service": "nutcracker",
"source": "localhost.localdomain",
"version": "0.4.1",
"uptime": 10,
"timestamp": 1452545028,
"total_connections": 303,
"curr_connections": 3,
"my_cluster": {
"client_eof": 300,
"client_err": 0,
"client_connections": 0,
"server_ejects": 0,
"forward_error": 0,
"fragments": 0,
"server1": {
"server_eof": 0,
"server_err": 0,
"server_timedout": 0,
"server_connections": 1,
"server_ejected_at": 0,
"requests": 246791,
"request_bytes": 11169484,
"responses": 246791,
"response_bytes": 1104215,
"in_queue": 0,
"in_queue_bytes": 0,
"out_queue": 0,
"out_queue_bytes": 0
},
"server2": {
"server_eof": 0,
"server_err": 0,
"server_timedout": 0,
"server_connections": 1,
"server_ejected_at": 0,
"requests": 353209,
"request_bytes": 12430516,
"responses": 353209,
"response_bytes": 2422648,
"in_queue": 0,
"in_queue_bytes": 0,
"out_queue": 0,
"out_queue_bytes": 0
}
}
}
Connection closed by foreign host.
还有其他基准可以正常使用吗?或者redis-benchmark
应该有效吗?
我忘了提到我使用的是Redis:3.0.6和Twemproxy:0.4.1
答案 0 :(得分:1)
这可能看起来有点违反直觉,但是将两个带有代理的redis实例放在它们面前肯定会降低性能!
在单实例场景中,redis-benchmark直接连接到redis服务器,因此每个请求的延迟最小。
一旦你把两个实例和一个twemproxy放在它们面前,想想会发生什么 - 你连接到twemproxy,它分析请求,选择正确的实例,并连接到它。
因此,首先,每个请求现在有两个网络跃点而不是一个。延迟增加意味着当然减少吞吐量。
此外,您只使用一个twemproxy实例。因此,让我们假设twemproxy本身或多或少像一个redis实例一样,你永远不会用一个代理打败一个实例。
Twemproxy有助于扩展,而不是扩展。它允许您将群集扩展到单个实例永远无法实现的大小。但是需要支付延迟价格,只要您使用单个代理,它也是吞吐量价格。
答案 1 :(得分:1)
代理商对每个请求征收小额税。使用具有一个服务器的代理测量吞吐量。施加负载直到吞吐量停止增长并且响应时间慢到爬行。添加另一台服务器并注意响应时间恢复正常,而容量只增加一倍。当然,您需要在响应时间开始爬行之前添加服务器。