.net HttpContext.Current.Application IIS中可以存储多少密钥是否存在限制/瓶颈？

我正在使用Couchbase作为密钥/值存储，最近我开始用HttpContext.Current.Application装饰最常用的缓存密钥

我首先从httpContext返回值（如果存在），否则从couchbase获取，然后保存到httpContext，然后返回值。这确保了下一次调用总是从httpContext获取值，如果出于某种原因IIS进行了回收，它将始终返回到从couchbase获取值，并且键值将被读回上下文

这种方法对我的应用程序的性能产生了巨大的积极影响，我正在考虑通过在这个装饰中添加更多的缓存键来扩展这个策略

但是，如果我们开始在HttpContext.Current.Application存储中存储大量键/值，恐怕会出现一些瓶颈。有人有这方面的经验吗？我有什么要担心的吗

假设我开始向HttpContext.Current.Application中填充大量数据。大小为10k+键及更多

请求是否会因为此存储包含大量数据而开始变慢

---

或者，它会因为我不断向其中插入大量数据而开始无休止地刷新自己吗？

HttpContext.Current.Application本质上是与经典asp向后兼容所需的遗留问题。它只是对.net for web application中静态全局HttpApplicationState对象的引用，每个web应用程序都应该有一个全局实例。通过在那里存储数据，您可以提供对全局变量的快速、线程安全的访问

---

考虑到它将通过iis重置而重置，您非常聪明。那么需要考虑的是服务器的数量和结构。如果要部署到单个web服务器，该方法将起作用。但是，如果要部署到web服务器场，应用程序通常只存在于单个服务器上下文中。

是的，我们正在部署到web服务器场，因此我知道我不能对每个web服务器之间需要始终保持最新的键/值使用此方法。但我对这种方法的担忧是，如果我开始向HttpContext.Current.Application中填充10k+键，那么就会出现严重错误。请求是否会因为此存储包含大量数据而开始变慢？或者，它是否会因为我不断向其中填充大量数据而开始无休止地刷新自身？通常，应用程序不会存储太多数据，也不会频繁刷新数据。存储更频繁使用的关键数据更为重要。这种类型的数据贯穿整个请求，调用将影响性能。应用程序实际上是一个静态全局对象。每次更新数据时，必须锁定、修改然后解锁。如果修改过于频繁，可能确实会导致速度变慢许多数据可能会导致站点性能变慢。如果可能，请使用较少的键和值，或者可以将键和值存储在数据库中，然后使用它。您应该查看System.Web.Caching命名空间以了解更高级的方案。此外，如果您在某种web场或集群中，您可能需要滚动您自己的全局数据存储，以便可以跨多个服务器共享它。