C#上的Redis哈希在WCF服务中速度非常慢

Question

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

我的vm是两个核心，有4GB的内存。

这是我正在尝试的代码。

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到实体查询需要0.25秒。

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

编辑：2013年12月7日

这似乎是WCF的问题。这篇使用Redis扩展Web服务的文章基本上反映了我的结果。我测试的是这个。

检索具有1683个对象的Redis哈希

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

WebApi和Node运行得很有魅力，运行速度接近我运行redis基准测试时的水平。

Answer 1

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

InitializeRelatedCollection（）

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

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

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