我目前正在通过 stackexchange.redis (1.0.4) 和 Windows RedisSessionStateProvider (1.6.2) 提供程序成功使用 Redis 的 Windows 端口(2.8.19 - MS Open Tech)来存储本地 session 。
将此配置与 session 的 InProc session 状态进行比较，我们注意到高负载下性能下降了约 20%。为了减少性能差距，我想知道使用 protobuf-net 序列化 session 是否可以有所帮助 - 这些模型具有必要的 proto 属性，但不完全确定如何配置 sessionStateProvider 来序列化它。
有人成功了吗？性能有提高吗？
此外，如果有任何其他建议来缩小性能差距，那就太好了。
编辑:这里是应用程序的 session key /大小(与此方法类似地测量: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**
提前谢谢您。
最佳答案
进程外存储比进程内存储慢是正常的，也是预期的:根据定义，进程内没有任何事情，而您现在需要构造命令，遍历 TCP，让服务器软件执行其操作，将 TCP 遍历回调用方，处理响应并反序列化。这是很多东西!
回答序列化问题很棘手，因为性能特征很大程度上取决于您的模型。这里有 4 种利息成本:
- 序列化CPU
- 有效负载大小(直接影响网络带宽)
- 网络延迟
- 反序列化CPU
如果现有提供商正在使用BinaryFormatter，我不会感到惊讶，在这种情况下，使用不同的序列化器(例如 protobuf-net)确实可能会降低 CPU 和带宽数量。如果主要因素是延迟:您无能为力。
顺便说一句:对于我们的一些内部用途，我们实际上使用 protobuf-net 和 GZipStream :我们发现，由于我们的数据往往包含相当多的文本，因此 gzip 减少的带宽超过了用于序列化/反序列化的额外 CPU。
但最重要的问题:您的 session 中有多少数据？
针对您的具体使用情况获得有意义的答案的唯一方法是:对其进行测量。
关于.net - Windows 上的 Redis 用于 session 状态性能和 protobuf，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29660139/