Windows 上的 Redis 用于会话状态性能和 protobuf

Question

我目前正在通过 stackexchange.redis (1.0.4) 和 windows RedisSessionStateProvider (1.6.2) 提供程序成功使用 Windows 端口的 Redis (2.8.19 - MS Open Tech) 来存储本地会话。

将此配置与会话的 InProc 会话状态进行比较，我们注意到在高负载下性能下降了约 20%。为了减少性能差距，我想知道使用 protobuf-net 序列化会话是否可以提供帮助 - 模型具有必要的 proto 属性，但不完全确定如何配置 sessionStateProvider 以使用它进行序列化。

有人搞定这个吗？性能提高了吗？

此外，如果有任何其他建议可以缩小性能差距，那也很好。

编辑：这里是应用程序的会话键/大小（测量方法与此方法类似：How to find out size of session in ASP.NET from web application?）

session key1 size: 38kB
session key2 size: 30kB
session key3 size: 37kB
session key4 size: 35kB
session key5 size: 35kB
session key6 size: 43kB
session key7 size: 33kB
session key8 size: 28kB
session key9 size: 42kB
session key10 size: 31kB
**TOTAL SESSION SIZE: 352kB**

提前谢谢你。

Answer 1

进程外存储比进程内存储要慢是正常且预期的：根据定义，进程内无事可做，而您现在需要构造命令，遍历 TCP，让服务器软件做它的事情，遍历 TCP 回到调用者，处理响应，反序列化。有很多东西！

回答序列化问题很棘手，因为性能特征在很大程度上取决于您的模型。这里有 4 种利息成本：

• 序列化 CPU
• 负载大小（直接影响网络带宽）
• 网络延迟
• 反序列化 CPU

如果现有提供程序使用BinaryFormatter，我不会感到惊讶，在这种情况下，使用不同的序列化程序（例如 protobuf-net）确实可能会降低 CPU 和带宽数量。如果主要因素是延迟：您将无能为力。

顺便说一句：对于我们的一些内部使用，我们实际上使用了 protobuf-net 和 GZipStream：我们发现由于我们的数据往往包含相当多的文本，gzip 减少的带宽超过了额外的 CPU序列化/反序列化。

但最重要的问题是：您的会话中有多少数据？

为您的特定用途获得有意义的答案的唯一方法是：对其进行衡量。