在 Session 和 Cache 中存储数据表有什么区别?有什么优点和缺点?
因此,如果它是一个简单的搜索页面,它在数据表中返回结果并将其绑定到网格视图。如果用户 'a' 搜索和用户 'b' 搜索,最好将其存储在 Session 中,因为每个用户很可能会有不同的结果,还是我仍然可以将他们的每个搜索存储在缓存中,或者这没有意义,因为有只有一个缓存。我想基本上我想说的是缓存会被覆盖。
一个重要的区别是,缓存中的项目可以在指定的时间后过期(将从缓存中删除)。放入会话中的项目将保留在那里,直到会话结束。
当可用内存量变小时,ASP.NET 也可以从缓存中删除项目。
另一个区别:会话状态可以保持在外部(状态服务器、SQL 服务器)并在 Web 应用的多个实例之间共享(用于负载平衡)。缓存不是这种情况。
除了这些差异(正如其他人所指出的):会话是每个用户/会话,而缓存是每个应用程序。
AFAIK,关键区别在于会话是每个用户,而缓存将用于应用程序范围的项目。
如其他答案所述,您可以将每个用户信息存储在缓存中,前提是您提供密钥(通过会话或 cookie)。然后,您可以更好地控制缓存中的项目过期并设置对它们的依赖关系。因此,如果有问题的 DataTable 会定期更改,那么缓存可能是一个合适的选择。否则,如果是静态会话可能更合适。Steven Smith 在 dnrtv 上有一个关于缓存的优秀视频,值得一看。
这真的取决于你想要达到什么目标,你有多少时间。关于如何在应用程序中存储状态,还有一些其他选择需要考虑。根据表的大小,您可以考虑将状态存储在 cookie 中(如果它是敏感信息,则加密)。或者,如果它是应用程序范围的数据,您可以在页面或类上使用静态字段。也有 Application 对象。
更新:我认为你必须问自己的关键问题是谁应该看到这些数据。
Are they going to access the data frequently?
(不,不要打扰)。
Is it going to change?
(不,使用静态字段或应用程序)。
Is it acceptable for user a and user b to see the same results?
(不,使用包含用户名和搜索词的键的缓存。)。
(是的,使用搜索词的键使用缓存)。
老实说,如果您的开发进度不远,我会考虑将缓存/状态问题留到以后 - 您甚至可能不需要它。
性能调优的前三个规则是:1. 测量,2. 测量更多。3. 再次测量...
另一个重要的区别是,如果执行并发异步 Ajax 请求, Session State 将被阻塞,这会影响性能
缓存属于Application范围,目的是减少获取一条数据的次数。会话位于用户的会话范围内,目的是提供特定的用户状态。
好吧,这取决于您如何为 ASP.NET 配置会话。您是将会话存储在数据库中还是在内存中?如果在内存中您是使用单独的服务器还是使用当前的网络服务器进行会话?
根据为您设置的方式,当您使用诸如数据表之类的东西时可能会影响性能,它告诉我您可能正在存储大量数据。
此外,Session 是按用户存储的,如果用户不接受 cookie 并且您已将 ASP.NET 设置为无 cookie 模式,则通过存储在 Session cookie 或 URL 上的 Session 票证按用户检索。您缓存的任何内容都将在应用程序级别进行缓存,并可供所有用户会话使用,这可能是您想要的,也可能不是您想要的。
会话是每个用户,缓存是应用程序。
缓存中的项目可以并且将根据过期时间(滑动或固定)和 IIS 工作进程的内存限制自动删除。
所以基本上 Cache 中的项目永远不会保证存在,但 Session 会一直留在那里直到会话结束。
按用户存储项目(通过 Session 或创造性地使用 Cache)会导致大量内存使用,应谨慎考虑。
除此之外,如果 IIS 重置工作进程,您可能会丢失缓存和会话。
看到这个答案。
除非您使用一些后端提供程序,例如 memcached 或速度,否则会话可能会影响您的应用程序性能。一般来说,你应该避免它。
据我所知,这完全取决于您的需求。
每当您需要为用户维护状态时,您在使用会话时必须非常小心。默认设置是“InProc”,它使用单个服务器的内存,在基于云的应用程序中效果不佳。这可能适用于那些在多实例网络农场环境中托管应用程序的人。Windows Azure 负载平衡器在连接的节点内使用循环分配。
您在会话存储中有多个选项。SQL Server 也可以用作会话状态的存储。azure 上提供了自定义会话技术,例如表存储提供程序等。
缓存也存储在服务器的内存中,但它与用户无关。同一池中的任何用户都可以访问应用程序缓存数据。总之,在云上,我们需要使用云提供商提供的缓存服务。Azure 提供 Windows Azure 分布式缓存服务。
事实上,当在应用程序中应用状态管理技术时,开发人员并不关心状态管理技术的影响。它
“如果您的客户没有云支持,那么您不必担心云场景”