如果在ASP.NET会话中缓存数据库中的数据,那么您将加快对该数据的后续请求(注意:取决于相关数据的序列化/反序列化成本),但代价是IIS中的内存负载。
(好吧,这可能是对现实情况的简化 - 随意纠正或改进我上面的陈述)
您是否使用任何规则(简单的经验法则或其他规则)来决定何时适合在会话中缓存?
可以使用会话来存储只读数据而不用经过深思熟虑理由只是被视为Premature Optimization的另一个案例? (因此,不好)
答案 0 :(得分:1)
如果您使用InProc模式,请记住会话中的缓存,除非您的代码在会话为空时返回到数据库,否则您将限制可伸缩性。您将被迫使用单个服务器或将您的用户固定到特定服务器。
如果使用会话状态服务器这不适用,并且如果使用SQL来存储会话状态,那么使用会话进行缓存是没有意义的。
有关此主题的任何建议都取决于您的具体环境。正如您所说,即使使用SQL会话状态,一个非常复杂的SQL查询也可能会受益于缓存。我认为最重要的是首先让您的应用程序执行功能并实现业务需求。然后返回测试并优化应用程序以处理您期望的负载。
根据您的更新,我不认为这是真的。在我的一个ASP.Net应用程序中,我使用会话状态来存储用户正在操作和修改的复杂对象模型。我们正在使用AJAX,因此当用户更新对象时,我们与服务器进行了很多短暂的通信。将对象保持在会话中是为了方便。该对象执行大量自定义计算以生成不同的数据点,因此在服务器上执行此操作是理想的,而不是尝试在servr和javascript中复制代码。同时保持会话可以让我们非常轻松地使用撤销功能。
是的,我知道我们牺牲了可扩展性,但我欢迎有一天,当我和老板坐下来解释我们有问题因为我们有太多用户(而且我知道他也会这样)。
所以我认为问题是为什么你在会话中存储数据是为了方便并在用户登录时提供对瞬态数据的访问?然后将其存储在那里以进行缓存。记住缓存的一件事是你要如何刷新缓存?你怎么弄无效?我没有建立会话状态来处理这个问题。
回到它之前只读数据,用户特定,从DB加载昂贵,继续在会话中缓存它。您可以编写代码,如果它不在会话中,那么您可以点击数据库。有一个很好的小助手类,可以通过你的网络应用程序隐藏它,你甚至可以使用会话,你应该是好的。关于隐藏你从网上存储它的好处,如果你发现遇到问题你只有一个地方可以改变它。
答案 1 :(得分:1)
鉴于很难保证会话中的数据在合理的时间范围内被清除,我会非常谨慎地兑现那里的奇数整数。当您达到大规模时,您将遇到内存问题或让所有用户都遇到会话超时错误。请记住,与Cache对象不同,当内存不足时,会话不会被终止。
同样,Josh说如果你去多个服务器并且需要使用数据库或会话状态服务器,你的会话对象将需要是可序列化的。在这种情况下,序列化和反序列化的成本可能比优化的查询的成本更差。