it-swarm.com.de

Wie kann ich die gzip-Komprimierung in IIS7 zum Laufen bringen?

Ich habe die statische und dynamische Komprimierung für IIS7 installiert und die beiden web.config-Werte auf der Ebene meiner Anwendung Virtual Folder eingestellt. Nach meinem Verständnis muss ich die Komprimierung nicht mehr auf Server- oder Site-Ebene aktivieren. Ich kann sie mithilfe der Datei web.config auf Ordnerebene verwalten.

Ich habe zwei Einstellungen in meiner .config-Datei, die ich zur Anpassung von gzip für meine App festgelegt habe:

<httpCompression dynamicCompressionDisableCpuUsage="90"
    dynamicCompressionEnableCpuUsage="0">
  <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
  <dynamicTypes>
    <remove mimeType="*/*"/>
    <add mimeType="*/*" enabled="true" />
  </dynamicTypes>
</httpCompression>
<urlCompression doDynamicCompression="true"
    dynamicCompressionBeforeCache="true" />

Beim Ausführen der Anwendung kann ich jedoch deutlich erkennen, dass gzip nicht verwendet wird, da meine Seitengrößen gleich sind. Ich benutze auch YSlow für FireFox, was auch bestätigt, dass meine Seiten nicht gepackt werden.

Was fehlt mir hier? In IIS6 mussten die Dateitypen einfach angegeben und der Komprimierungsgrad zwischen 0 und 10 eingestellt werden. Ich sehe keine Notwendigkeit, die Dateitypen oder die Komprimierungsstufe anzugeben, da die Standardeinstellungen die Dateitypen abdecken und ich die Ebene nirgendwo sehe.

68
Russ

Es gab einen Thread auf forums.iis.net während der Beta von iis 7. Es stellte sich heraus, dass der Typ die Module nicht installiert hatte, aber es hört sich an, als hätten Sie das aus Ihrem ersten Satz ausgeschlossen.

Microsofts wichtigster Ratschlag für ihn war es, die Suche nach fehlgeschlagenen Anforderungen zu ermöglichen, um herauszufinden, was schief lief. Dies ist möglicherweise eine der am wenigsten geschätzten Funktionen von IIS7, aber sicherlich eine der mächtigsten. 

  • Öffnen IIS Manager.
  • Gehen Sie zu Ihrer Site und klicken Sie im Aktionsbereich (ganz rechts) auf "Failed Request Tracing ..." im Abschnitt "Configure".
  • Klicken Sie auf "Aktivieren". 
  • Klicken Sie anschließend in der Funktionsansicht auf "Regeln für die Ablaufverfolgung für Anforderungsfehler". Klicken Sie auf Hinzufügen, geben Sie als nächstes 200 als Statuscode ein und klicken Sie anschließend auf Fertig stellen.

Wenn im Aktionsbereich "Fehlgeschlagene Anforderungsprotokollierung" nicht angezeigt wird, müssen Sie die Funktion zum Server hinzufügen - entweder mit dem Assistenten "Rollendienste hinzufügen" (Integritäts- und Diagnoseverfahren) oder über das Web Platform-Installationsprogramm (Products\Server\IIS: Tracing) und dann schließen und erneut öffnen IIS Manager.

Führen Sie anschließend den Test erneut aus. Dadurch werden einige Protokollinformationen generiert, die wir prüfen können.

Suchen Sie in c:\inetpub\logs\FailedReqLogFiles\w3svcx. Sie werden eine Reihe von Dateien mit dem Namen fr000xx.xml sehen. Öffnen Sie eine davon in Ihrem Browser. (Übrigens, wenn Sie diese Dateien irgendwo kopieren, stellen Sie sicher, dass freb.xsl vorhanden ist. Löschen Sie außerdem nicht freb.xsl. Wenn Sie dies tun, löschen Sie einfach das gesamte Verzeichnis oder kopieren Sie es von einem anderen Speicherort, wie IIS erstellt es nur einmal pro Ordner.)

Klicken Sie auf die Registerkarte "Anforderungsdetails" und wählen Sie "Anforderungsablaufverfolgung abschließen". Suchen Sie auf der Seite nach "komprimieren" - Sie sollten sie in mehreren Bereichen finden; einmal für statischen Inhalt und einmal für dynamischen Inhalt. 

Wenn Sie keine davon finden, ist IIS nicht richtig konfiguriert. Wenn Sie sie finden, sollten Sie sie gefolgt von einem compression_success und einem compression_do sehen. Erfolg ist selbsterklärend; Das "do" zeigt an, was es getan hat - in meinem Fall wurde "OriginalSize 1462784 CompressedSize 179482" angezeigt.

Da Ihre nicht funktioniert, werden Sie hoffentlich etwas anderes sehen, das Ihnen hilft, das Problem zu lösen.

Stellen Sie sicher, dass Sie diese Option deaktivieren, wenn Sie fertig sind, indem Sie die Ablaufverfolgung für fehlgeschlagene Anforderungen im Aktionsbereich Ihrer Website deaktivieren.

62
JohnW

Wir hatten ein ähnliches Problem und es stellt sich heraus, dass IIS7 hier ein dynamisches CPU-basiertes Throttling durchführt.

http://www.iis.net/ConfigReference/system.webServer/httpCompression

dynamicCompressionDisableCpuUsage

Optionales uint-Attribut.

Gibt den Prozentsatz der CPU-Auslastung an, bei dem die dynamische Komprimierung deaktiviert wird.

Hinweis: Dieses Attribut fungiert als obere CPU-Grenze, bei der die dynamische Komprimierung deaktiviert ist. Wenn die CPU-Auslastung unter den im Attribut "dynamicCompressionEnableCpuUsage" angegebenen Wert fällt, wird die dynamische Komprimierung wieder aktiviert.

Der Standardwert ist 90.


dynamicCompressionEnableCpuUsage

Optionales uint-Attribut.

Gibt den Prozentsatz der CPU-Auslastung an, unterhalb dessen die dynamische Komprimierung aktiviert wird. Der Wert muss zwischen 0 und 100 liegen. Die durchschnittliche CPU-Auslastung wird alle 30 Sekunden berechnet.

Hinweis: Dieses Attribut fungiert als untere CPU-Grenze, unterhalb derer die dynamische Komprimierung aktiviert ist. Wenn die CPU-Auslastung über den im Attribut "dynamicCompressionDisableCpuUsage" angegebenen Wert steigt, wird die dynamische Komprimierung deaktiviert.

Der Standardwert ist 50.

Beachten Sie die Standardwerte. Wenn Ihr IIS7 eine CPU-Auslastung von 90% erreicht, wird alle dynamischen komprimierten Inhalte deaktivieren, bis die CPU-Auslastung wieder unter 50% fällt.

Außerdem einige großartige Empfehlungen und Benchmarks zu den tatsächlichen CPU-Kosten von GZIP.

http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx

Lange Rede, kurz gesagt, es sei denn, Sie haben regelmäßig dynamische Seiten mit weit über 200 KByte.

27
Jeff Atwood

Dem hervorragenden Rat von JohnW folgend, habe ich auch die Protokollierung aktiviert, um den Täter zu finden, obwohl sich der Grund für den Fehler als anders herausstellte:

STATIC_COMPRESSION_NOT_SUCCESS 
Reason 14 
Reason NOT_FREQUENTLY_HIT

Kurz gesagt, es scheint, dass wenn Sie die Seite nicht oft genug besuchen, IIS7 sie nicht für komprimierbar hält, was mir ein bisschen seltsam erscheint. Trotzdem macht es in diesem Fall Sinn, weil ich es gerade auf einem lokalen Rechner testen wollte.

Gemäß dieser Seite scheint der Standard zu sein, dass eine Seite innerhalb von 10 Sekunden zweimal getroffen werden muss, um ein häufiger Treffer zu sein. Wenn Sie wirklich möchten, können Sie den Standard in applicationHost.config (% systemroot%\Windows\System32\inetsrv\config) überschreiben. Zumindest für mich ist es ein gesperrtes Attribut, sodass Sie es nicht in Ihrer eigenen web.config überschreiben können.

<serverRuntime frequentHitThreshold="1" />

Ich stelle auch fest, dass SO diese Antwort hier bereits hatte: In IIS7 bleiben gzip-Dateien nicht so .

21
Gavin

Ich habe mein Problem durch Installieren der dynamischen Komprimierung unter "Programme hinzufügen/entfernen" gelöst.

5
Eduardo

Fügen Sie im Abschnitt system.webServer Ihrer Datei Web.config die folgenden Zeilen hinzu:

<remove fileExtension=".js" />  
<mimeMap fileExtension=".js" mimeType="application/x-javascript" />  

Das Komprimierungsschema in IIS7 ist standardmäßig aktiviert, es wird jedoch nur ein einziger zu komprimierender Javascript-Mime-Typ (application/x-javascript) zugeordnet. Wenn Sie die Zeile oben hinzufügen, wird IIS angewiesen, allen Ihren .js-Dateien diesen Mime-Typ zu geben, wodurch die Komprimierung funktioniert.

5
jvenema

aktivieren Sie die statische Komprimierung. Die dynamische Komprimierung ist für dynamische Seiten wie ASP, PHP, ASPX usw. geeignet.

Hier ist ein Link zur IIS - Konfigurationsreferenz für die Komprimierung

3
Darren Kopp

Für mich war es die Einstellung

noCompressionForProxies

da wir hier auf einem Stellvertreter sind ... nahm ich mich von Stellvertreter und voila ab, Kompression.

0
µBio