ASP.Net SQLServer 会话状态与直接数据库访问
在我正在开发的网站上，我为返回的注册用户保存了许多“用户首选项”（例如，每页显示的产品摘要数量）。我很好奇在 ASP.Net SQLServer 会话状态中存储/检索这些数据与根据需要直接从数据库检索数据相比是否有任何性能优势。非常感谢！
On the website I am developing, I have a number of "user preferences" that I keep stored for my returning, registered users (for example, the number of product summaries per page to display). I am curious if there is any performance benefit to storing/retrieving this data in an ASP.Net SQLServer Session State versus retrieving it as-needed directly from my database. Many thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要数据不是太大，将数据存储在会话状态（性能角度）总是更好。这样，您的生产数据数据库（您保存用户数据的地方）的点击率就会减少。只需确保用户不会更改缓存在会话中的首选项即可。
会话的唯一潜在问题是会话是按用户维护的。因此，如果您的网站上有太多用户，会话状态就会增加，但由于您使用 SQL Server 作为会话存储，因此您可以很好地做到这一点。如果您使用 InProc SessionMode，您的会话将位于内存中（生产服务器上的关键资源！）
Its always better to store Data in Session State (performance point of view), as long as the data isn't too Huge. This way, you Production Data Database (where you persist your UserData) Hits would reduced. Just make sure that User Wouln't change his preferences which are cached in session.
Only potential problem with session is that Session is maintained per User. so, if there are too many users on your website, session state grows but since you are using SQL Server as you Session Store, you are good on that. Had you been using InProc SessionMode, your Session would have been in memory (a critical resource on production servers!)
无论如何，你都会受到 sql server 的影响。因此，您不应该对性能产生明显的影响，而且如果使用 sql server 进行会话状态 - 您不必太担心实现细节 - 因此可能会更容易使用。但没有——没有主要好处。有人可能会说这取决于您如何存储/查找信息，但对于大多数应用程序来说，这里的差异绝对可以忽略不计 - 这取决于您想要如何实现。现在，如果您远离 sql server 会话状态，那么您还有另一组需要关注的问题（应用程序重置等），但这不在您要求的范围内:)
You are taking the hit going to sql server anyways. So you shouldn't have a noticeable performance impact and also if using sql server for session state - you don't have to worry much about the implementation details - hence could be a 'bit' easier to use. But no - there is no main benefit. one could argue it depends on how you store/lookup your information but for most apps the difference here is absolutely negligible - it's up to you how you want to implement. Now if you ever move away from sql server session state then you have another set of issues to be concerned over (app resets, etc) but thats not in the scope of what you asked : )