我目前通过stackexchange.redis（1.0.4）和windows RedisSessionStateProvider（1.6.2）提供程序成功使用Redis的Windows端口（2.8.19 - MS Open Tech）来存储内部会话。< / p>
比较此配置与会话的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**
提前谢谢。
答案 0 :(得分：2)
正常并且预计进程外存储将比进程中慢：根据定义，进程内无关，而您现在需要构建命令，遍历TCP，让服务器软件执行其操作，将TCP遍历回调用者，处理响应和反序列化。那是很多东西！
回答序列化问题很棘手，因为性能特征在模型上依赖非常。这里有4项成本：
如果现有提供商使用BinaryFormatter，我不会感到惊讶，在这种情况下，使用不同的序列化程序（如protobuf-net）确实可能会降低CPU和带宽数量。如果主导因素是延迟：你做不了多少。
顺便说一句：对于我们的一些内部用途，我们实际使用protobuf-net和GZipStream：我们发现由于我们的数据往往包含相当多的文本，因此gzip减少的带宽超出了额外的CPU来序列化/反序列化。
但最重要的问题是：您的会话中有多少数据？
为特定用途获得有意义答案的唯一方法是：测量它。