Cela peut être une question hérétique d'une certaine manière. Nous avons un grand site où beaucoup de pages sont encore en ASP. La plupart du temps, il n'y a pas vraiment de dynamique mais ils incluent (via SSI ou Server.Execute) des morceaux de HTML périodiquement régénérés. Cela peut ressembler à la mise en cache d'un pauvre, mais cela fonctionne très bien et je suppose que Microsoft a fortement optimisé IIS pour ce scénario.Fonctionnalité SSI dans ASP.NET/ASP.NET MVC
Maintenant, nous aimerions pouvoir réaliser quelque chose de similaire dans ASP.NET/ASP.NET MVC. Nous aurons des extraits de code HTML générés périodiquement (généralement toutes les heures) que nous aimerions inclure dans les wrappers ASP.NET/ASP.NET MVC fournissant le chrome du site principal, de la navigation, et éventuellement d'autres contenus dynamiques liés aux snippets. Donc, c'est un mélange, mais le fait est que le HTML généré est périodiquement re-généré par un processus externe principalement pour des raisons de performances et de synchronisation de notre batterie de serveurs.
La chose la plus proche dans ASP.NET, j'ai pu trouver était:
<% Response.WriteFile("GeneratedSnippet.inc"); %>
qui semble être équivalent à la
<% Server.Execute "GeneratedSnippet.inc" %>
en ASP. C'est peut-être même plus rapide car il n'y a pas de code à exécuter. Mais il est peut-être pas aussi efficace que:
<!--#include file="GeneratedSnippet.inc" -->
Comme je l'ai mentionné plus haut, je soupçonne que IIS a été optimisé pour gérer déchaussement SSI ainsi que ASP comprend au fil des ans. D'un autre côté, le fichier Response.WriteFile lit très probablement le fichier et le recrache. Quelqu'un aurait-il un aperçu de deux ou une certaine expérience? Peut-être que je m'inquiète trop, mais la plupart de notre contenu lourd de trafic fonctionne encore sur ASP et utilise beaucoup de SSI, et donc même une petite différence dans Response.WriteFile peut s'accumuler et avoir un impact visible.