查询数据库或缓存较小结果集的性能更好？

Question

假设我需要使用数据库填充4或5个带有项目的下拉菜单。 每个下拉列表中有<15个项目。 这些项目几乎永远不会改变。

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

对我而言，写作是微不足道的，但是我不确定性能是否会更好。 我认为会（尽管可能不会很大）。

你怎么看？

Answer 1

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

1. 首先以最简单的方式做事（避免过早优化）
2. 使用设定的性能目标对代码进行性能测试（例如，在N个并发用户的负载下，响应时间为200毫秒）
3. 然后， 如果您的代码没有执行，则对您的代码进行分析以确定运行缓慢，然后对建议的性能修复进行分析，以准确衡量实际的性能变化。

话虽这么说，是的，您的建议似乎是明智的（您通常希望内存中的缓存比数据库快），但是这还取决于返回的数据，应用程序的内存负载，查询有多昂贵，查询参数是什么等等。

您应该在更改前后进行性能测试，以确定更改的实际效果（包括内存负载之类的东西），并且只有在确定这些下拉列表是导致不可接受的性能问题的原因之后，才应该这样做。 。

Answer 2

这就是System.Web.Helpers.WebCache类的用途。

Answer 3

IO通常比内存操作更昂贵（数量级）。 尤其是如果您的数据库在另一台计算机上，那么您甚至会使用网络资源，仅使用缓存肯定会更快。

但实际上，当您通过测量将其真正确定为性能瓶颈时，最后进行优化。

Answer 4

快速回答您的问题：

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

需要考虑的其他要点。

1. 最好在一次数据库检索中（考虑存储过程和数据集）检索所有主数据：但是，我不主张在所有情况下都使用存储过程。
2. 正确地说，在往返数据库之前，请确保您的数据访问层检查高速缓存
3. 另外，由于您的下拉值不会经常更改； 请记住要保持很长的有效期
4. 最后，根据您的页面设计，您还可以查看Fragment Caching（部分页面缓存：用户控件），它可以为您带来更大的好处，因为现在您既不访问数据缓存也不访问数据库。

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