1

我是 Redis 新手，开始使用 redis 哈希来存储一些对象，我遇到了一些非常意想不到的性能问题。我在本地托管在 vmware 播放器上的 Ubuntu 机器上运行 redis。

我的虚拟机是两个核心，4 GB 内存。

这是我正在尝试的代码。

using (var redis = new RedisClient())
{              
    using (var client = redis.As<MyClass>())
    {
        var hash = client.GetHash<Guid>("urn:class");                   
        var items = hash.Values;
    }
}

哈希包含从我们的实体模型添加的大约 2000 个项目。在我的运行过程中，要从哈希中取出所有值需要 7 秒，即使对于我实例中 redis 的一点硬件，这似乎也很高。对相同数据的普通 LINQ to Entity 查询需要 0.25 秒。

我在这里做错了什么吗？考虑到我听到的所有关于 redis 性能的好消息，这似乎是错误的。

编辑：2013 年 7 月 12 日

这似乎是一个 WCF 问题。这篇文章Using Redis to Scale Web Services基本上反映了我的结果。我所做的测试是这样的。

使用 1683 个对象检索 Redis 哈希

  • IIS 中的 WCF 服务：7 秒
  • ASP.NET Web API：0.8 秒
  • NodeJS 只是为了好玩：0.8 秒

Web Api 和 Node 运行起来就像一个魅力，运行起来接近我运行 redis-benchmark 的时代。

4

1 回答 1

1

我的问题在于我用作 Redis 客户端上下文的类。该类是使用带有对象上下文的旧版本实体框架生成的实体模型。生成实体的方式导致 ServiceStack.Redis 客户端必须做大量工作来反序列化从 Redis 返回的对象。实体导航属性的 set 方法调用

初始化相关集合（）

每次 json 解析器必须反序列化通过 Redis 客户端返回的对象时都会调用它。在没有导航属性的情况下切换到更简单的对象效果很好，并使时间恢复到我预期的与我的其他测试一致的数字。

我没有在 ASP.NET Web API 中看到这种放缓的原因是因为实体是使用新的 DbContext 模型生成的，而 ServiceStack 中的 Json 序列化程序几乎不需要做它在 WCF 中所做的工作量项目，因为导航属性只是简单的列表或集合。

首先将实体对象作为 Redis 客户端的类型可能不是一个好主意。

于 2013-07-13T03:44:54.860 回答