问题标签 [asp.net-session]

We are experiencing a large number of connections between asp.net and redis. During a 15 minute span we see connections ramp up to about 33,000 per second then slowly taper off after several hours. We are using v2.0.1-Preview of the ASP.NET Session State Provider.

我有以下 PowerShell 脚本，旨在使用表单身份验证登录网站。似乎尽管没有错误/返回的状态代码始终为 200，但脚本并没有超出登录页面。使用 Fiddler 进行一些初步研究我发现ASP.Net_SessionId当通过浏览器访问该站点时正在创建一个 cookie，而通过我的脚本访问时该 cookie 不存在。

关于问题可能是什么的任何提示，或者我如何更深入地了解这里发生的事情？先感谢您。

假设我在我的 Web 应用程序中使用 MVC，并且我有一个包含多个控制器的区域...... MyController1，MyController2和MyController3

这些控制器由某些组中的用户使用：UserGroup1、UserGroup2和UserGroup3。我会将组 ID 存储在会话中。

我希望客户端请求看起来像这样通用：www.mysite.com/MyArea/MyController/SomeAction

那么，如何根据会话中存储的组 id 变量分配相应的控制器？

一些伪代码：

我知道我可以点击控制器并执行重定向，但是堆栈中是否有更高的位置我可以更好地控制控制器分配。

我已经从复选框列表中动态创建了复选框，并将此列表保存到会话中，并希望在复选框的 onChange 事件中从会话中获取此复选框列表。这是代码。

var a = '<%= Session["chk"]%>'; 此行返回System.Collections.Generic.List1[System.CheckBox]而不是列表 processChechBox(id)，在每个选中的复选框上都会调用此函数。

我们正在为移动客户端使用 Web API 开发 REST API。特别需要在服务器端保留用户特定的数据（昂贵的 DAL 请求）。

这样做的最佳做法是什么？

• 天真的方法是将数据保存在应用程序的内存中。
• 考虑到安全问题，我们正在考虑使用 ASP.NET Session。

你会推荐什么？
第三方云解决方案不是一种选择。

谢谢！

在我的应用程序中，用户将登录，在他们登录后，我需要以某种方式跟踪他们刚刚创建的会话。一旦他们登录，他们有两个选择，进入建筑物并完成登录过程或为他们的会话检查设备。我需要在应用程序中跟踪该会话以进行项目签出。但是我不想在设备视图之前在每个视图中传递当前会话模型？目前我正在使用 TempData，但我觉得这是在玩火，因为我在某个地方读到了我相信的两次重定向后临时数据被清除的地方？是否有永久临时数据或其他我可以使用的更安全的数据？谢谢您的帮助。

我们可以使用SessionStateModeSQLServer 为会话变量提供持久性存储。为什么我们不需要应用程序变量的灵活性？是因为它们的大小应该非常小（所有用户都通用）吗？

如果我们正在考虑一个 .net Web Farm，我们可能需要使这些应用程序变量保持一致。SessionStateMode 也可以存储应用程序变量吗？我看到一个表[ASPStateTempApplications]，但它只有列AppId，AppName。

我正在研究存储TempData在一个更好的地方。有一个如何使用 MongoDB 执行此操作的演练，但用于存储的密钥（item.SessionIdentifier == controllerContext.HttpContext.Request.UserHostAddressIP 地址）显然不起作用，因为多个用户/会话可以共享相同的公共 IP。

使用 IP 作为密钥的后果是多个用户将看到（并删除）彼此的数据。特别是，在您的开发机器上进行测试期间，所有会话和浏览器实例都将共享相同的临时数据。

TempData在某些数据库中用于存储的好键是什么？

我尝试在本地运行的每个 aspnet Web 应用程序都不再保留会话。
不知何故，这发生在具有不同项目的 VS 2013 和 2015 上。我什么都没碰，一天早上我发现重定向后每个会话数据都丢失了。
这些应用程序仍在生产和开发环境中运行。

偶尔我会收到 100 到 200 个 redis 超时异常。因为我在 redis 上使用会话（通过官方的 MS 包），所以这些对客户端来说变成了“500s”/yellow-screen-of-death。

使用应用程序洞察力调查这些超时，我发现根本原因是一些“评估”命令。我使用术语“一些”是因为keyHashSlot报告的异常消息各不相同。

该异常还报告可用的 IOCP 和 Worker 线程（最小值为 100，通常有 10 多个空闲）

那么，我怎样才能更深入地研究并弄清楚为什么这些 Eval 变暗了呢？它们是否因为它们的内容（它被执行的脚本）而超时？还是他们在队列上浪费了太多时间？