2010-07-27 67 views
3

这可能是一种异端问题。我们有大量的网站,许多网页仍然在ASP中。大多数情况下,它们并不是真正动态的,但它们包括(通过SSI或Server.Execute)定期重新生成的HTML块。它可能看起来像一个穷人的缓存,但它一直工作得很好,我猜测微软已经针对这种情况大量优化了IIS。ASP.NET/ASP.NET MVC中的类SSI功能

现在,我们希望能够在ASP.NET/ASP.NET MVC中实现类似的功能。我们将定期生成我们希望包含在ASP.NET/ASP.NET MVC包装中的HTML代码片段(通常每小时左右),这些包装提供主站点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中的一点点差异也可能会积累并产生可见的影响。

回答

1

你有什么问题吗? :)

SSI已死亡。是的,它在SERVER SIDE上进行了高度优化,但它不仅可以缓存控制器,还可以在浏览器中缓存控制。

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

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