What to put in a session variable我最近遇到了一个ASP 1.1 Web应用程序，该应用程序将一堆东西放在会话变量中-包括所有DB数据对象，甚至是DB连接对象。 最终变得巨大。 当Web会话超时(用户使用完应用程序四个小时)后，有时其数据库事务将回滚。 我假设这是因为在IIS终止会话时，数据库连接未正确关闭。 无论如何，我的问题是会话变量中应该包含什么？ 显然，这里需要一些东西。 用户在主屏幕上选择要编辑的计划，因此计划ID进入会话变量。 最好通过在会话变量中存储有关用户(及其管理员等)和他们正在编辑的计划的所有详细信息来减少数据库的负载，还是应该尽量减少会话变量和 查询数据库以获取我在Page_Load事件中所需的一切？ 这很难回答，因为它是如此特定于应用程序的，但是这里是我使用的一些准则： 从您对应用程序的评论中，我可能会从数据库中选择您的数据，并尝试找到使这些查询的影响最小化的方法，而不是加载会话。 不要在会话中放入数据库连接信息。 至于缓存，如果可能的话，我会避免使用会话进行缓存-您会遇到其他人更改用户正在使用的数据的问题，而且您将无法在用户之间共享缓存的数据。使用ASP.NET缓存或其他一些缓存实用程序(如Memcached或Velocity)。 至于会话中应进行的操作，适用于用户已打开到您站点的所有浏览器窗口的所有内容(登录，安全设置等)都应在会话中。诸如正在查看/编辑的对象之类的东西实际上应该是在屏幕之间传递的GET / POST变量，以便用户可以使用多个浏览器窗口来与您的应用程序一起使用(除非您希望避免这种情况)。 不要将UI对象放入会话中。 除此之外，我会说它有所不同。如果您不使用进程内会话，那么过多的会话可能会减慢您的速度，因为您将要进行大量的序列化以及提供程序的速度。缓存和会话应谨慎使用。不要仅仅因为可以或方便而进行会话。坐下来分析是否合理。 理想情况下，ASP中的会话应存储最少的数据量。存储对保持系统资源开放(尤其是数据库连接)的任何对象的引用是绝对的可伸缩性杀手。同样，在大多数情况下，将未提交的数据存储在会话变量中也是一个坏主意。总的来说，这听起来像当前的实现正在滥用会话对象来尝试在一个无状态的环境中模拟一个有状态的应用程序。 尽管存在很多弊端，但是通过隐藏字段自动管理状态的ASP.NET模型应该真正消除了将任何内容保留在会话变量中的大部分需求。 我的经验法则是，应用程序需要的扩展性(就用户/点击量而言)越多，使用会话状态就越难以捉摸。但是，需要进行权衡。对于用户重复访问相同数据并且每次使用站点通常会话时间较长的Web应用程序，某些缓存(如果需要，在会话对象中)实际上可以通过减少DB服务器的负载来帮助实现可伸缩性。这里的想法是，与后端数据库相比，存储表示层的成本要低得多，也要复杂得多。当然，无论如何，此建议应谨慎处理，并不能在所有情况下都适用，但是对于一个相当简单的内部CRUD应用程序，它应该可以很好地为您服务。 我将始终在会话中保留很少的信息。会话使用昂贵的服务器内存资源。在会话中保存太多的值会增加服务器的负载，最终站点的性能将下降。使用负载平衡服务器时，会话的使用可能会遇到问题。因此，我要做的是使用最少的会话或不使用任何会话，如果信息不是很关键，则使用cookie，更多地使用隐藏字段，并使用数据库会话。
斯蒂芬， 答：仅与一个用户有关的数据。 IE：用户名，用户ID。最多一个代表用户的对象。有时，相对于URL的数据(例如到某人那里去)或错误消息栈对于将其推送到会话中很有用。 如果要在不同用户之间共享内容，请使用应用程序存储或缓存。他们远胜于此。 在会话中存储导航提示非常棘手。同一用户可以打开多个窗口，然后以混乱的方式传播更改。数据库连接绝对不应存储。 ASP.NET可以为您维护连接池，而无需诉诸您自己的魔术。如果您需要短时间缓存内容，并且数据集的大小相对较小，则可以考虑使用ViewState(以将更多的批量加载到页面大小为代价) 之前，有关PHP会话的问题也非常类似。基本上，会话是存储需要在多个页面加载中访问的用户特定数据的好地方。会话不是存储数据库连接引用的好地方。您最好使用某种连接池软件，或者在每次页面加载时打开/关闭连接。至于在会话中缓存数据，这取决于会话数据的存储方式，所需的安全性以及该数据是否特定于用户。更好的选择是将其他内容用于缓存数据。 |
