查询DB或Cache小结果集的性能更好？

Question

假设我需要从数据库中填充4或5个带有项目的下拉列表。每个下拉将具有＆lt;其中15项。这些项目几乎不会改变。

现在我可以在每次访问页面时查询数据库，或者我可以从自定义类中获取值，以检查它们是否已存在于ASP.Net的缓存中，并且只有在它们不查询数据库时才更新缓存。

这对我来说是微不足道的，但我不确定性能是否会更好。我认为会是（虽然不太可能是巨大的）。

您怎么看？

Answer 1

在处理性能问题时，您应该始终：

1. 首先采用最简单方式（避免过早优化）
2. 使用设置效果目标对您的代码进行性能测试（例如，在N个用户的负载下，响应时间为200毫秒）
3. 然后， IF 您的代码无法执行，然后对您的代码进行概要分析，以确定哪些内容很慢，并对您提出的性能修补程序进行分析，以准确衡量实际性能变化。

说完然后是的，你所建议的似乎是明智的（你通常会期望内存缓存比数据库更快），但是它还取决于返回的数据，你的内存负载是多少应用程序是，查询有多贵，查询参数是什么等等......

您应该对之前和之后的更改进行性能测试，以确定更改的实际效果（包括内存加载等），并且只有在确定更改后才应该执行此类操作这些下拉列表是造成不可接受的性能问题的原因。

Answer 2

这就是System.Web.Helpers.WebCache类的存在。

Answer 3

IO通常比内存操作（按数量级）更昂贵。特别是如果您的数据库在另一台机器上，那么您甚至可以使用网络资源，并且使用缓存肯定会更快。

但实际上，当你通过测量确定它是一个性能瓶颈时，最终会进行优化。

Answer 4

快速回答您的问题：

1. 使用内置的.Net缓存。

思考的其他要点..

1. 最好在单个数据库检索中检索所有主数据（想想存储过程和数据集）：但是，我并不主张在所有方案中使用存储过程。
2. 正如您所说，确保您的数据访问层在进行数据库往返之前检查缓存
3. 此外，由于您的下拉值不会经常变化;记得保持很长的到期时间
4. 最后，根据您的页面设计，您还可以查看片段缓存（部分页面缓存：用户控件），这可以为您带来更大的好处，因为现在您既不访问数据缓存也不访问数据库。

性能： 同样，与您获取主数据的直接往返相比，性能更多地取决于应用程序的负载。简而言之，As Thomas建议使用缓存类！