2011-01-09 5 views
3

Es gibt merkwürdiges Verhalten beim Caching von Ausgaben in einer ASP.NET 4-Anwendung in IIS 7.5. Ich konnte das Problem einfach auf anderen leeren Setups wiederholen, ich bin mir sicher, dass dies ein Fehler ist, aber ich bin mir nicht sicher, wie ich es an Microsoft melden soll.IIS7.5 OutputCacheModule-Kernel-Caching 'public' Ignorieren der URL

Eine Website in IIS antwortet auf mehr als 1 Domäne, die .NET-Anwendung prüft den Hostnamen und erstellt den Inhalt entsprechend. Beispielsweise kann es den Name der Anforderungs-URL in einer leeren Seite drucken. ZB www.first-domain.com und www.second-domain.com

Die Datei web.config verfügt über das entsprechende Caching, urlCompression und httpCompression, die alle unter dem Knoten system.webServer deaktiviert sind.

Die aspx-Seite legt den Cache-Control-Header für public fest, entweder mit einem zukünftigen Datum für Verfallsdaten oder einem Höchstwert.

Wenn Sie www.first-domain.com besuchen, wird die Seite ausgegeben, die erfolgreich 'www.first-domain.com' geschrieben hat.

Wenn Sie jedoch www.second-domain.com aufrufen, wird eine Seite ausgegeben, die 'www.first-domain.com' schreibt.

Untersuchen der failed-request-traces, System.Web.Caching.OutputCacheModule hat die zwischengespeicherte Ausgabe gefunden (obwohl die .config-Dateien die Funktion deaktiviert haben), der Cache ist identisch, obwohl der Hostname der Anforderungs-URL unterschiedlich ist und daher gibt die zweite Anforderung die Ergebnisse der ersten Anforderung an die andere Domäne aus, solange das maximale Alter/Ablauf festgelegt wurde, bevor die richtige Seite für die zweite Domäne angezeigt wird.

Entweder die Einstellung cache-control auf private, oder das Entfernen des 'OutputCache' Moduls in der web.config löst das Problem, während die korrekten Cache-Control-Header an den Browser gesendet werden, aber offensichtlich kann ich keinen Vorteil daraus ziehen von Kernel-Caching, wenn ich es brauche.

Ich kann keine MSDN-Dokumentation finden, wie das OutputCacheModule konfiguriert ist.

Hat jemand anderes dieses Problem erlebt, wie kann ich das Kernel-Caching aktivieren und den URL-Hostnamen berücksichtigen (ohne die Anwendung auf verschiedene Sites in IIS zu trennen)?

Danke.

Update:

Hinzufügen SetSlidingExpiration hat keine Auswirkung, da der Kernal-Cache noch die Ausgabe unabhängig von der Anforderung Host-Namen-Caches. Das einzige Szenario besteht jetzt darin, das Ausgabe-Caching zu deaktivieren oder eine doppelte Instanz der Anwendung auf jeder ausgeführten Domäne auszuführen. Angesichts des Rückgangs der Serverleistung im Vergleich zur Leistungssteigerung bei der Verwendung des Ausgabecachings haben wir uns entschieden Deaktivieren der Ausgabezwischenspeicherung für diese App

Antwort

2

Keine Antwort nach 9 Monaten wurde zur Verfügung gestellt und keine Lösung gefunden wurde, nur eine Behelfslösung, vielleicht wird dies in der nächsten Version von IIS festgelegt wird mehr als 7,5 ...

-

Das Hinzufügen von SetSlidingExpiration hat keine Auswirkungen, da der Kernel-Cache die Ausgabe immer noch zwischenspeichert, unabhängig vom Hostnamen der Anfrage. Das einzige Szenario besteht jetzt darin, das Ausgabe-Caching zu deaktivieren oder eine doppelte Instanz der Anwendung auf jeder ausgeführten Domäne auszuführen. Angesichts des Rückgangs der Serverleistung im Vergleich zur Leistungssteigerung bei der Verwendung des Ausgabecachings haben wir uns entschieden Deaktivieren der Ausgabezwischenspeicherung für diese App

+0

Ich stehe vor einem sehr ähnlichen Problem.Hier jedoch bringt mich das Deaktivieren von Ausgabe und Kernel-Cache nur bis "Application_BeginRequest". Controller werden nicht aufgerufen, und benutzerdefinierte Header, die ich in "Application_BeginRequest" festgelegt habe, haben keine Auswirkungen. – Juliano

0

Ich habe ähnliches Problem. Ich benutze benutzerdefinierte URL-Rewriter. Ich habe Seiten example.com/articles und example.com/art-ANY_ID.html. Beide URLs sind auf articles.aspx (im zweiten Beispiel als articles.aspx? Id = ANY_ID) abgebildet. Es funktionierte gut mit ASP.NET 2.0 und Classic-Pipeline-Modus. Nachdem wir es in ASP.NET 4 und den integrierten Modus geändert haben, haben wir seltsames Verhalten: Beide URLs geben identische Ausgaben zurück. Es war jede Seite wie beispiel.com/art-ANY_ID.html.

Jetzt haben wir <add extension=".html" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" /> aus Abschnitt <caching enabled="true" enableKernelCache="true"> entfernt und es funktioniert gut. Ich verstehe nicht, warum http.sys es zwischenspeichern.

Haben Sie irgendwelche Erklärungen gefunden?

2

Ich hatte ein sehr ähnliches Problem und keine Lösungen hier half mir.

TLDR: Gewaltsam das OutputCache Modul auf dem Web.config Entfernung war die einzige Lösung, fand ich.

Mein Szenario war ein bisschen anders.

Ich habe CORS in Application_BeginRequest einrichten, Access-Control-Allow-Origin für bestimmte Hosts zu beantworten, die mich anrufen (es * Einstellung ist zuverlässig gewesen).

Mein Controller setzt auch Cache-control: public für seine Antworten.

Was ich fand

Immer, wenn ich Cache-control: public gesetzt, IIS-Caches mit Gewalt die Antwort. Haltepunkte auf entweder Application_BeginRequest oder meinem Controller wurden nie ein zweites Mal getroffen.

Deaktivieren Ausgang und Kernel-Caching über die IIS-Manager als unter gesehen hätte ich die Application_BeginRequest Haltepunkte schlagen, aber nie hat mich in den Controller. Irgendetwas puffte immer noch Antworten. disabled output caching and kernel caching on inetmgr

This article schlug der Output Modul von IIS helfen würde, zu entfernen.

<system.webServer> 
    <modules runAllManagedModulesForAllRequests="true"> 
    <remove name="OutputCache" /> 
    </modules> 
</system.webServer> 

Dadurch konnte ich mein Controller endlich treffen.

Was noch mehr

Wenn jemand von MS helfen würde oder kein Licht leuchten könnte, ob es einen Weg gibt, dieses Verhalten zu ändern. OutputCache könnte in einigen Teilen einer Anwendung nützlich und in anderen nicht notwendig sein.

Vielleicht Vorsicht bin ich (wir sind?) Hier das falsche Problem zu lösen.

Vielleicht übernahm IIS Caching in diesem Szenario, weil es sollte. Vielleicht würden sich Proxies auf dem Weg zwischen meinem Server und dem Benutzer genauso verhalten wie in diesem exakten Szenario, und wenn das der Fall ist, ist es falsch, auf IIS zu arbeiten. Ich muss das herausfinden und vielleicht solltest du es auch tun.

Verwandte Themen