IIS ASP.NET InProc会话变量未随机写入会话

关于导致InProc会话丢弃会话对象的事情，有很多信息，但这里并不是这样。我们在稳定的InProc会话对象中缺少单个变量，并且不确定这些变量是没有被写入，还是在成功写入后丢失。我已经向WinDBG确认，会话是实时的，并且包含一些（但不是全部）写入会话的数据

Guid g = System.Guid.NewGuid();
this.Context.Session.Add(g.ToString(), result.ImageData);           
output.Write("<img src=\"display.aspx?id=" + g.ToString() + "\">");

这段代码非常简单，在测试中可以完美地工作。但在生产过程中，在重载情况下，故障率约为1%。如果Smith先生访问该站点并试图显示4条图像数据，其中2条可能会在他的会话中保存，2条可能会丢失

Smith先生的InProc会话对象存在。流量日志显示他点击了4次，每次都有不同的id参数。但是在他的InProc会话对象中只有2个guid，而不是4个。我们捕获的2个会话对象与流量日志中显示的2个id相对应，分别是他的第一次和第三次单击。不过，他第二次和第四次单击的流量日志显示的guid id不在他的InProc会话对象中

上述代码的第1行和第3行显然适用于第2次和第4次单击，否则他在URI中就没有可以单击的id。然而，第2行似乎以某种方式悄无声息地失败了。如果抛出任何异常，我希望我们永远不会到达第3行。我看不到用户接收guid id的任何方法，但会话无法接收guid id。另一种可能性是第2行工作成功，但变量后来消失了，我甚至无法想象

还有谁能想到别的吗？或者是一个建议来重新解释这样的问题

详情： ASP.NET v3.5 IIS 6 没有网络园艺

---

我们正在运行一个web服务器场，但用户不断返回同一服务器。我现在正在研究是否有任何方法可以让用户滑到另一台服务器

要想知道问题是否是由于负载平衡器和粘性会话造成的，一个简单的方法是完全停止使用它，看看问题是否会再次出现

如果不可能，您可以将会话存储在进程外[state server]，然后再次检查会话。我曾在微软全球技术支持部门工作过，在很多情况下，粘性会话根本不起作用

---

在您的情况下，如果可能，您可以通过在服务器场中的每台服务器上使用相同的机器密钥来绕过粘性会话的需要

---

我会让moeny看到人们溜到另一台服务器。在过去也看到过类似的情况，粘性会话并不总是按照他们在锡上说的做！考虑到高负载，是否可能内存不足？你分析过这个吗？还有，你也在开发中经营农场吗？是的。滑动。我不是一个网络人，我误解了全局站点选择器与内容交换机相比的功能。我们生活和学习。至于记忆，我确实深入研究过，这是一个很好的建议。谢谢你的建议。我们正在查看out-proc，但暂时不可能关闭开关。实际上，用户正在访问不同的服务器场成员。我们正在使用一个全局站点选择器，而不是我们通常的内容交换路由解决方案。GSS发送一个或另一个IP地址以响应客户端的DNS查询。DNS回复上的TTL为20秒，这意味着DNS回复过期的时间太短，不实用。短期解决方案是延长TTL。长期的解决方案是进程外会话管理。实际上，machineKey解决方案使用的是ViewState，而不是会话状态。InProc会话状态不是machineKey加密的，因此在我的情况下不会有任何影响。我们的机器已经在我们所有的农场同步很久了。