与算法相关的愚蠢问题：如何在考虑时间的情况下计算命中/未命中缓存比率

Question

好吧，我确定这是某处问题的重复（我拒绝相信我是唯一为此苦苦挣扎的白痴），但我找不到它。

这在纸上看起来很容易，但我还是要写这个。

所以，我写了自己的缓存系统。 已经完成了 99%。 我缺少最后一块拼图：让系统决定从缓存加载是否“有利可图”（时间明智）。

我有 4 个变量：

• hit ：从缓存中成功加载的计数器

• miss ：从缓存中加载失败的计数器

• time_check ：从缓存中加载的平均时间（hit和time_check同时更新）

• time_generate ：从头开始生成页面的平均时间（miss 和 time_generate 同时更新）

从那里，我的问题听起来很简单。 我需要找出一个公式或一组 if-elses 条件来决定是否尝试从缓存加载。

假设变量已经存在是安全的，因为算法只会在至少加载 100 个页面后运行。

需要考虑的一件重要事情是，如果算法决定从缓存中加载但未命中，则总加载时间将为time_check + time_generate ！

Aaaand...从那里我不知道我应该怎么做。 我卡住了。 我的头脑无法处理这个。

我需要系统根据获得实际时间收益的概率做出正确的决定，从缓存中加载内容。

我已经可以从一开始就说，如果 time_generate < time_check，我们不应该使用缓存，无论命中与未命中。 但是，对于 rest，我感到困惑。

有没有人读到这篇文章有 flash 的大脑并且能够立即理解我在寻找什么？ :)

Answer 1

我有 4 个变量：

您的time_check是 2 件 - 检查数据是否在缓存中，然后从缓存中获取数据。 如果您检查数据是否在缓存中，但不是，您最终会得到“(part of time_check ) + time_generate ”，并且您没有信息可以推断出“part of time_check ”。

您需要通过将time_check分成几部分来解决这个问题 - 例如time_check_if_cached和time_fetch_from_cache 。

您忽略了第 5 个变量 - 您尝试确定是否应该检查缓存所花费的时间。 这还应该包括跟踪用于做出决定的信息所花费的时间（例如，增加hit和未miss ）。 让我们称之为time_decision 。

现在你有 3 个案例：

1. 您决定不检查缓存。 它花费time_decision + time_generate 。

2. 你决定检查缓存，发现数据没有被缓存。 它花费time_decision + time_check_if_cached + time_generate 。

3. 您决定检查缓存并发现数据已缓存。 它花费time_decision + time_check_if_cached + time_fetch_from_cache 。

现在我们可以确定一些通用规则：

a) 如果time_decision大于或等于time_check_if_cached ； 那么最好跳过time_decision并改为检查缓存。 这是最有可能发生的情况。 结果是您只有 2 个案例 - time_check_if_cached + time_generate和time_check_if_cached + time_fetch_from_cache 。

b) 如果time_decision仅略小于time_check_if_cached ，并且缓存命中的可能性很小； 总是跳过time_decision仍然“平均而言更好”。

c) 如果time_decision明显小于time_check_if_cached ； 您有设计缺陷，需要修复/优化time_check_if_cached 。

d) 如果命中率 ( hit/(hit+miss) ) 如此之低（并且time_check_if_cached如此昂贵）以至于您认为避免time_check_if_cached和 go 直接到time_generate可能会有所帮助； 那么你有设计缺陷，需要修复/提高命中率。

e) 如果time_check_if_cached + time_fetch_from_cache大于或等于time_generate ； 你有设计缺陷，要么需要修复/优化time_check_if_cached + time_fetch_from_cache ，要么停止尝试缓存已经快到缓存无能为力的东西。

Answer 2

我花了很多时间思考这个问题，经过无数次尝试，我终于找到了满足我需求的答案。 如果有人需要它：

跳过所有计算和简化，最终公式为：

minimum hit rate % = time_check / time_generate

我想你可以从这里的其他回复中以某种方式找到它。

接下来，根据该基本公式，我们需要扭曲时间以惩罚更高的时间。 这是因为，在统计和概率方面，在 3.5 秒内减掉 2.5 秒等同于在 350 秒内减掉 250 秒。 然而，这不是我们“感受”时间的方式。 我们更愿意下注输掉 2.5 秒而不是 250 秒。 如果我们打赌输掉 250s 而不是 350s，我们会期望非常高的命中率。 如果我们打赌 2.5 秒超过 3.5 秒：“我的意思是，它只有 2.5 秒，所以这不是什么大问题，我们还是试试吧”。

我根据随机尝试尝试了很多选项，但我最后保留的选项是：

minimum hit rate % = arctan(time_check/100) / arctan(time_generate/100)

我没有任何理由，它最适合我的需要。 它也可以通过改变分母来适应。 /50 将使其更严格（需要更高的命中率），/150 将使其更灵活（所需的命中率更低）。 它适合所有范围的值，并给出相当可预期的结果。

我想这完全取决于您的特定配置，以下是我尝试过的其他时间扭曲选项及其问题：

• time_check² / time_generate² [对高距离值太宽松]
• time_check ^ 0.1 / time_generate ^ 0.1 [整体过于严格]
• 1.05 ^ time_check / 1.05 ^ time_generate [总的来说太严格了]
• 1.1 ^ time_check / 1.1 ^ time_generate [在高距离值上太宽松]
• log2(time_check) / log2(time_generate) [不适合 1 及以下的值]