Architecture 资源表示的预生成

我的假设是-

• 表达具有具有其上次修改日期的定义。例如，生成资源JSON表示的脚本在上次修改该脚本时已更改
• 资源的持久存储没有任何存储限制

现在的情况是，我有一些资源，它们的表示可以是预先生成的或动态生成的；其中，预生成的指的是在修改资源时生成的文本/html或应用程序/atom+xml（可以异步完成），而动态生成的指的是在请求时生成表示的JSP/PHP脚本

---

我感到困惑的是，与动态生成+缓存相比，预生成的性能增加了多少？您的经验/观点是什么？

绩效收益与产生绩效所需的努力成比例；因此，如果构建一个表示需要大量的资源（可能还需要时间），那么缓存是一个好主意

---

因此，您需要做的第一件事是测量构建表示的过程，并确定性能影响发生的位置。

您询问性能，但没有指出应该执行什么，因此我假设度量是“响应时间”

这两种方法只是彼此的变体。预生成只是缓存的另一种方式。所以实际上，唯一的区别是一个是“懒惰的”，而另一个不是

因此，当所有资源都已缓存（且不更改）时，延迟的差异将为零。但性能差异因几个参数而异：

• 生成项目所需的时间
• 每个项目更改的次数
• 每个项目的访问频率

引爆点是指如果一个项目被修改的次数少于被访问的次数

但还有很多其他因素需要考虑：

• 预生成方案的伸缩性更好，因为如果请求数量增加，它们不需要额外的CPU
• 预生成方案更具容错性，因为应用程序的关键路径中不涉及数据库
• 如果资源X中的一个更改（例如，它被删除）导致1000个其他资源发生更改（例如，如果它们都链接到X），则预生成方案可能很难实现。这将增加资源被修改的频率高于被访问的频率的可能性

---

如何处理删除是一个进退两难的问题，但如果我们思考如何进行超链接，目标资源不知道它正在进行超链接，但我们知道。因此，如果目标被删除，我会说我们有责任更新我们的资源。自动删除关系（如删除时的SQL级联）仅为方便起见。在我的情况下，我希望读的次数至少是写的100倍，如果不是更多的话！预生成的一个问题是，如果在生成表示后表示生成器发生了更改，该怎么办？我们是否只生成？或者，当要求代表时，我们是否检查更改？