Lassen Sie mich zunächst erklären, warum ich diesen Artikel geschrieben habe und warum ich mit diesem kleinen Problem zu kämpfen habe. Erstens ist die Aktivierung der gzip-Komprimierung statischer Dateien sehr nützlich, um die Zugriffsgeschwindigkeit der Website zu verbessern und die Zeit zu reduzieren, die Spider für das Crawlen statischer Seiten benötigen. Gleichzeitig werden dadurch keine 200 0 Baidu-Spider verursacht wie das Aktivieren der dynamischen Dateikomprimierung. 64-Crawling-Problem, daher ist eine schnelle Website-Geschwindigkeit einerseits förderlich für die Verbesserung der Benutzererfahrung. Andererseits hat der Google-Administrator-Blog in diesem Jahr deutlich gemacht, dass die Website-Geschwindigkeit einer der Ranking-Faktoren ist, und zwar für die Verwendung ausländischer Hosts Die Optimierung und der unbefriedigende Zeitaufwand für den Aufbau chinesischer Baidu-Websites führen dazu, dass Baidu Spider weniger Crawling durchführt. Guoping erwähnte dies auch bereits in seinem Blog-Artikel: Wie wirkt sich die Ladegeschwindigkeit von Webseiten auf den SEO-Effekt aus? In einem festgelegten Zeitraum ist die Gesamtzeit festgelegt, die ein Spider zum Crawlen der Website benötigt. Wenn die Crawling-Geschwindigkeit steigt, erhöht sich die Anzahl der gecrawlten Seiten und umgekehrt.
Okay, beginnen wir mit dem Haupttext. In Frage 2 des vorherigen Artikels „Experimentelle Ergebnisse des Spinnens statischer Seiten und Auslösen der gzip-Komprimierung“ habe ich eine Vermutung darüber angestellt, wie die komprimierte Version statischer gzip-Seiten auf dem Server gespeichert wird Ich war lange verwirrt Danach stellte ich fest, dass der letzte Grund für die unterschiedlichen gzip-Ergebnisse, die von den beiden Hosts zurückgegeben wurden, die IIS-Version war und nicht die Einstellung des Cache-Ordners, die meiner Meinung nach zu klein war.
Tatsächlich verfügt iis7 über ein größeres Update als iis6 bei der statischen Komprimierung. In IIS6 wird die statische Komprimierung in einem anderen Thread durchgeführt, sodass nach dem Empfang einer HTTP-Anfrage die erste an den Browser gesendete HTML-Version unkomprimiert ist und IIS6 gestartet wird Verwenden eines anderen Threads zum Komprimieren der Datei und Speichern der komprimierten Version im Cache-Ordner der komprimierten Datei für längere Zeit. In der Vergangenheit rief IIS6 auf dem IIS6-Server nach Abschluss der Komprimierung bei jeder HTTP-Anfrage für die komprimierte Version der statischen Datei die komprimierte Version direkt aus dem Cache-Ordner auf und gab sie an den Browser zurück.
Aber in IIS7 wird die Komprimierung im Hauptthread durchgeführt, und um Komprimierungskosten zu sparen, speichert IIS7 keine langfristig komprimierten Versionen aller HTTP-Anfragen, sondern nur statische Dateien, auf die Benutzer häufig zugreifen Als ich es zum ersten Mal besuchte, wurde die komprimierte Version zurückgegeben, als ich es nach kurzer Zeit erneut besuchte, aber die unkomprimierte Version wurde zurückgegeben, als ich es nach ein paar Minuten besuchte. Hier können wir verstehen, dass IIS7 die komprimierte Version nicht tatsächlich im Cache-Ordner speichert, sondern nur im Serverspeicher speichert oder die komprimierte Version vorübergehend im Cache-Ordner speichert und nach einer Weile löscht.
Die Methode für IIS7, um zu definieren, auf welche Dateien häufig zugegriffen wird und welche Komprimierungsstandards eingehalten werden, sind die folgenden zwei Eigenschaften in system.webServer/serverRuntime: FrequentHitThreshold und FrequentHitTimePeriod. Wenn IIS innerhalb des FrequentHitTimePeriod-Zeitraums Zugriff auf eine statische Datei erhält, die den FrequentHitThreshold-Schwellenwert überschreitet, komprimiert IIS7 die statische Datei wie IIS6 und speichert die komprimierte Version für lange Zeit im Cache-Ordner der komprimierten Datei. Wenn im Cache-Ordner bereits eine zwischengespeicherte Version der Datei vorhanden ist, wenn ein Benutzer auf eine Datei auf der Website zugreift, beurteilt IIS7 die Logik von frequentHitThreshhold nicht mehr und gibt die komprimierte Version direkt an den Browser zurück.
Diese Einstellung ist zwar sehr schmerzhaft, die offizielle Antwort von Microsoft lautet jedoch, dass damit die Serverleistung verbessert werden kann. . . Wenn Sie also möchten, dass IIS7 wie IIS6 komprimieren kann, gibt es zwei Lösungen. Natürlich ändern beide die Werte von FrequentHitThreshold und FrequentHitTimePeriod:
Die erste besteht darin, den folgenden Inhalt zu web.config hinzuzufügen, „frequentHitThreshold“ auf 1 und „frequentHitTimePeriod“ auf 10 Minuten anzupassen
<system.webServer>
<serverRuntime aktiviert=true
frequentHitThreshold=1
häufigHitTimePeriod=00:10:00/>
</system.webServer>
Die zweite Methode besteht darin, %windir%/system32/inetsrv/appcmd.exe zu öffnen, dann die folgende Befehlszeichenfolge in die Befehlszeilenschnittstelle einzugeben und dann die Eingabetaste zu drücken
set config -section:system.webServer/serverRuntime -frequentHitThreshold:1
Vertreter von Microsoft schlagen vor, dass ein weniger radikaler Ansatz nicht darin besteht, „frequentHitThreshold“ zu senken, sondern „frequentHitTimePeriod“ zu erhöhen, was für die Serverleistung moderater ist. Was ich hier erwähnen möchte, ist, dass es für Freunde, die über VPS verfügen, empfohlen wird, es manuell festzulegen. Ob Benutzer virtueller Hosts dies tun können, hängt vom Dienstanbieter ab. Leider kann ich es nicht ändern. Jeder, probiert es aus