在 ASP.NET(包括 MVC)中使用会话变量的替代方法

发布于 2024-08-14 04:27:24 字数 735 浏览 3 评论 0原文

如果之前有人问过这个问题,我很抱歉,但我还没有完全找到我脑子里的具体问题。

对于我正在构建的网站(使用 ASP.NET MVC) - 性能是一个重要特征。此外,该网站有可能托管在应用程序池每 20 分钟回收一次(如果达到内存阈值则更快)的环境中。我希望完全独立于会话变量,而是将类似 GUID 的值存储在 cookie 中。我的理由是 - 由于 AppPool 回收,我不知道会话将持续多长时间,并且不希望他们的会话过早超时并导致他们必须重复登录。

cookie 中的 GUID 值将充当表的查找键,我在该表中存储类似会话的信息(用户 ID 值等)。因此,如果我需要这些数据,我可以从数据库中检索它。我仍然会利用 Session_OnEnd 事件来清除会话表中“上次活动”值超过 20 分钟的行(或者无论会话配置为持续多久)。所以我想我仍然会使用会话状态,而不是会话变量。

不过,我再次担心的是性能。因此,我很好奇是否有更好的方法来避免使用会话变量,同时仍然保持了解用户是谁并以“类似会话”的方式管理他们对网站的访问的能力。我仍然是 MVC 的新手,但多年来在 ASP.NET 方面拥有丰富的经验,因此,我希望我的问题有意义!

编辑:我有点回避想要使用 SQL 会话状态,因为我可能处于共享 sql 服务器托管环境中,并且不认为我将拥有能够创建/运行作业(如果需要删除)的登录名过期的 sql 会话数据等。在 AppPool 回收场景中依赖 Session_OnEnd 和 cookie 是否有任何真正的缺点?当 AppPool 回收时,Session_OnEnd 是否无法对当前会话执行?

I apologize if this has been asked before, but I haven't quite found the specific question I have in my head.

For the website I am building (using ASP.NET MVC) - performance is an important feature. Also, there is a chance that the site could be hosted in an environment where the Application Pool gets recycled every 20 minutes (or sooner if the memory threshold is reached). I would like to be completely independent of relying on session variables and instead, store a GUID-like value in a cookie. My reasoning is - I don't know how long the session will last because of the AppPool recycling and don't want their session to timeout prematurely and cause them to have to login repeatedly.

The GUID value in the cookie would act as a lookup key to a table where I store session-like information (a user ID value, etc.). So if I needed that data I could retrieve it from the database. I would still make use of the Session_OnEnd event to clear out that session table of rows with a "last activity" value of more than 20 minutes old (or however long sessions are configured to last). So I guess I would still be using session state, just not session variables.

My concern though, again, is about performance. Therefore, I was curious if there are any better methods for avoiding use of session variables while still maintaining the ability to know things about who the user is and manage their visits to the site in a "session-like" way. I am still a newbie to MVC but have plenty of experience in ASP.NET over the years so, I hope my question makes sense!

EDIT: I'm kind of shying away from wanting to use SQL Session State because I will likely be in a shared sql server hosting environment and don't think I will have a login with the ability to create/run jobs if necessary for deletion of expired sql session data, etc. Are there any real drawbacks to depending on Session_OnEnd with a cookie in the AppPool recycling scenario? Could Session_OnEnd not execute for sessions that are current when the AppPool recycles?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

淡水深流 2024-08-21 04:27:24

您假设会话仅存储在工作进程中,您可以拥有 SQL 状态会话,在进行任何操作之前检查此链接进一步

You are assuming Sessions are only stored in the working process, you can have SQL State sessions, check this link before going any further

空城缀染半城烟沙 2024-08-21 04:27:24

使用数据库在网络农场/花园中提供“持久”持久性是一种常见技术。还有分布式缓存系统,可用于跨服务器和重新启动提供会话状态数据。

例如,我见过的分布式系统之一使用 UDP 在多个服务器之间共享会话数据。我预计分布式缓存会带来一些性能优势,因为数据存储在服务器的内存中,因此不需要数据库查找。

Using a database to provide "durable" persistence across web farms/gardens is a common technique. There are also distributed caching systems that can be used to make session state data available across servers and reboots.

For example, one of the distributed systems I've seen uses UDP to share session data across multiple servers. I would expect there is some performance benefit with distributed cache because the data is stored in memory on the servers, so there is no database lookup.

空心↖ 2024-08-21 04:27:24

如果您无法使用进程内状态,则必须恢复到外部存储库,该存储库可能是数据库。

那么为什么不将会话状态存储在数据库中呢?有对此的内置支持,它有效地解决了回收问题,同时在会话状态保持较小的情况下保持可接受的性能。

If you cannot use in-process state, you'll have to revert to an external repository, which will likely be the database.

So why not having the session state stored in the DB? There's built-in support for that, and it solves the recycling issue effectively, while keeping an acceptable performance if the session state is kept small.

最单纯的乌龟 2024-08-21 04:27:24

研究自定义缓存机制。就像您所说的,您不能使用会话变量,因为听起来您的网站将进行负载平衡?由于应用程序池的回收,会话可能会发生变化。您也不希望视图状态的开销(您可以使用它,但它会影响性能)。

缓存和其他提到的模型之间存在三个关键区别:

  1. 缓存是线程安全的
  2. 缓存中的项目会自动删除 缓存
  3. 中的项目支持依赖项

Look into a custom caching mechanism. Like you said you cannot use session variables as it sounds like your web site will be load balanced? Sessions may change due to the recycling off the app pool. You also don't want the over head of View State (you could use this but it will impact performance).

There are three key differences between Caching and the other mentioned models:

  1. Caching is thread safe
  2. Items in cache are removed automatically
  3. Items in cache support dependencies
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文