ASP.NET / ASP.NET MVC 中类似 SSI 的功能
在某种程度上，这可能是一个异端问题。我们有一个大型网站，其中很多页面仍然采用 ASP。大多数情况下，它们并不是真正动态的，但它们包括（通过 SSI 或 Server.Execute）定期重新生成的 HTML 块。它可能看起来像一个穷人的缓存，但它运行得非常好，我猜测 Microsoft 已经针对这种情况对 IIS 进行了大量优化。
现在，我们希望能够在 ASP.NET / ASP.NET MVC 中实现类似的功能。我们将定期生成 HTML 片段（通常每小时左右），我们希望将其包含到 ASP.NET / ASP.NET MVC 包装器中，提供主站点镶边、一些导航以及可能与片段相关的一些其他动态内容。所以它是一个混合体，但重点是生成的 HTML 会由外部进程定期重新生成，主要是出于性能原因并保持我们的服务器场同步。
我能找到的 ASP.NET 中最接近的东西是：
<% Response.WriteFile("GeneratedSnippet.inc"); %>
这似乎相当于
<% Server.Execute "GeneratedSnippet.inc" %>
ASP.NET 中的。它可能更快，因为没有代码要执行。但它可能不如：
<!--#include file="GeneratedSnippet.inc" -->
正如我上面提到的，我怀疑 IIS 多年来一直在大力优化以处理 SSI 和 ASP 包含。另一方面，Response.WriteFile 很可能真正读取文件并将其吐出。有人会深入了解两个或一些经验吗？
也许我担心太多了，但我们的大多数流量大的内容仍然在 ASP 上运行并使用大量 SSI，因此即使 Response.WriteFile 中的一点差异也可能会累积并产生明显的影响。
This may be a heretic question in a way. We have large site where lot of pages are still in ASP. Mostly, there are not really dynamic but they include (via SSI or Server.Execute) periodically regenerated chunks of HTML. It may look like a poor man's caching, but it has been working really well and I'm guessing that Microsoft has heavily optimized IIS for this scenario.
Now, we would like to be able achieve something similar in ASP.NET / ASP.NET MVC. We will have periodically generated HTML snippets (typically hourly or so) which we would like to include into ASP.NET / ASP.NET MVC wrappers providing the main site chrome, some navigation, and possibly some other dynamic content related to the snippets. So it's a mixture, but the point is that the generated HTML are periodically re-generated by an external process mainly for performance reasons and keeping our server farm in sync.
The closest thing in ASP.NET I was able to find was:
<% Response.WriteFile("GeneratedSnippet.inc"); %>
which seems to be equivalent to the
<% Server.Execute "GeneratedSnippet.inc" %>
in ASP. It's perhaps even faster because there is no code to execute. But it's not perhaps as efficient as:
<!--#include file="GeneratedSnippet.inc" -->
As I mentioned above, I suspect that IIS has been heaving optimized to handle SSI as well as ASP includes over the years. On the other hand, the Response.WriteFile most likely really reads the file and spits it out. Would anybody have an insight into two or some experience?
Maybe I worry too much, but most of our traffic heavy content still runs on ASP and uses lot of SSI's, and so even a little difference in Response.WriteFile may accumulate and have a visible impact.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你问什么问题？ :)
SSI 已经死了。是的，它在服务器端进行了高度优化，但是不仅在服务器中而且在浏览器中缓存控件可能不是很有效。
如果您使用太多 SSI，服务器将必须为每个请求检查所有相关文件的修改状态。您无法控制 HTTP 标头，例如 Expires 和 ETag。
ASP.NET 和 ASP.NET MVC 提供了很多方法来控制和使缓存失效，这可以提供更好的整体性能、更可扩展的设计和更好的可维护性代码。
What is you question ? :)
SSI is dead. Yes it was highly heaving optimized on SERVER SIDE, however it might not very effective to cache control in not only in server but also in browsers.
If you use too many SSI, the server will have to check all related files' modified status for each request. You cannot control HTTP headers for example Expires and ETag.
There are (too) many way provided in ASP.NET and ASP.NET MVC to control and to invalidate caches, which can give better overall performance, and more scalable design and better codes in maintainability.