ASP.NET / ASP.NET MVC中类似SSI的功能

时间:2010-07-27 15:46:22

标签: asp.net asp.net-mvc ssi

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

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

我能找到的最接近的东西是:

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

似乎等同于

<% Server.Execute "GeneratedSnippet.inc" %>
ASP中的

。它可能更快,因为没有代码可以执行。但它的效率可能不如:

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

正如我上面提到的,我怀疑IIS已经进行了优化以处理SSI以及ASP包括多年来。另一方面,Response.WriteFile很可能真正读取文件并将其吐出。有人可以洞察两种或一些经验吗?

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

1 个答案:

答案 0 :(得分:1)

你有什么问题? :)

SSI已经死了。是的,它在SERVER SIDE上进行了高度优化,但不仅在服务器中而且在浏览器中缓存控制可能不是非常有效。

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

ASP.NET和ASP.NET MVC中提供了很多方法来控制和使缓存无效,这可以提供更好的整体性能,更可扩展的设计和更好的可维护性代码。