3

这在某种程度上可能是一个异端问题。我们有大型网站，其中很多页面仍在 ASP 中。大多数情况下，它们并不是真正动态的，但它们包括（通过 SSI 或 Server.Execute）定期重新生成的 HTML 块。它可能看起来像一个穷人的缓存，但它运行得非常好，我猜微软已经针对这种情况对 IIS 进行了大量优化。

现在，我们希望能够在 ASP.NET / ASP.NET MVC 中实现类似的功能。我们将定期生成 HTML 片段（通常每小时左右），我们希望将其包含到 ASP.NET / ASP.NET MVC 包装器中，提供主站点 chrome、一些导航，以及可能与片段相关的一些其他动态内容。所以这是一种混合，但关键是生成的 HTML 会定期由外部进程重新生成，主要是出于性能原因和保持我们的服务器场同步。

我能找到的 ASP.NET 中最接近的东西是：

<% Response.WriteFile("GeneratedSnippet.inc"); %>

这似乎相当于

<% Server.Execute "GeneratedSnippet.inc" %>

在 ASP 中。它可能更快，因为没有要执行的代码。但它的效率可能不如：

<!--#include file="GeneratedSnippet.inc" -->

正如我上面提到的，我怀疑 IIS 多年来一直在优化以处理 SSI 以及 ASP 包括在内。另一方面， Response.WriteFile 很可能真的会读取文件并将其吐出。有人会深入了解两个或一些经验吗？

可能是我太担心了，但是我们大部分流量大的内容仍然在 ASP 上运行，并且使用了大量的 SSI，因此即使 Response.WriteFile 的一点差异也可能会累积并产生明显的影响。

4

1 回答 1

1

你有什么问题？:)

SSI 死了。是的，它在服务器端进行了高度优化，但是不仅在服务器中而且在浏览器中缓存控制可能不是很有效。

如果您使用过多的 SSI，服务器将不得不检查每个请求的所有相关文件的修改状态。您无法控制 HTTP 标头，例如 Expires 和 ETag。

ASP.NET 和 ASP.NET MVC 提供了（太多）多种方法来控制和使缓存无效，这可以提供更好的整体性能、更具可扩展性的设计和更好的可维护性代码。

于 2010-07-28T14:30:52.807 回答