gpt4 book ai didi

.net - .net ServiceStack.Redis 客户端的 twemproxy(胡桃夹子)性能下降

转载 作者:IT王子 更新时间:2023-10-29 06:10:12 29 4
gpt4 key购买 nike

在 CentOS 6.4 上安装 redis 和 nutcracker。并尝试使用 ServiceStack.Redis 客户端进行连接。发现主要性能问题。

测试只留下1个redis实例

beta:
listen: 0.0.0.0:22122
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
#timeout: 5000
#server_retry_timeout: 2000
#server_failure_limit: 3
redis: true
servers:
#- 127.0.0.1:6379:1
- 127.0.0.1:6380:1

在下面的单元测试中,我试图通过胡桃夹子将 100k 字符串发送到 redis。

[TestClass]
public class RedisProxyTest
{
public string host = "192.168.56.112";
//public int port = 6379;
public int port = 22122;

[TestMethod]
public void TestMethod1()
{
var key = "l2";
var count = 100000;
using (var redisClient = new RedisClient(host, port))
{
var list = new List<string>();
for (int i = 0; i < count; i++)
{
list.Add(Guid.NewGuid().ToString());
}

Utils.TimeLog("Remove", () => redisClient.Remove(key));

Utils.TimeLog("AddRangeToList", () => redisClient.AddRangeToList(key, list));
}

using (var redisClient = new RedisClient(host, port))
{
redisClient.GetListCount(key);

Utils.TimeLog("GetRangeFromList", () =>
{
var ret = redisClient.GetRangeFromList(key, count / 2, count - 1);
Console.WriteLine(ret.Count);
});
}

}
}

在胡桃夹子重新启动后的前几次运行中,AddRangeToList 工作了 1-2 秒。但是随着后续运行 AddRangeToList 性能从几分钟甚至超过 20 分钟显着下降(如果没有配置超时)。直接使用 redis 时我无法重现。我还没有尝试任何其他客户端。有什么想法吗?

这是我在单元测试运行后在控制台中看到的:

Test Name:  TestMethod1
Test Outcome: Passed
Remove: 0.0331171
AddRangeToList: 806.8219166
50000
GetRangeFromList: 1.741737

最佳答案

看起来这个问题与传输该数量的数据时内存使用率过高有关。

默认情况下,nutcracker 为每个键分配 16k 缓冲区大小。在我的例子中,它将是 16k*100000 = 1.5Gb。在观看胡桃夹子过程时,我看到了大约 2Gb 的峰值。我的 Cent OS VM 过载,没有足够的内存来处理这个峰值。

关于.net - .net ServiceStack.Redis 客户端的 twemproxy(胡桃夹子)性能下降,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20014030/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com