Primero permítanme explicarles por qué escribí este artículo y por qué estoy luchando con este pequeño problema. En primer lugar, activar la compresión gzip de archivos estáticos es muy útil para mejorar la velocidad de acceso al sitio web y reduce efectivamente el tiempo que tardan las arañas en rastrear páginas estáticas. Al mismo tiempo, no causará 200 0 a las arañas de Baidu. como activar la compresión dinámica de archivos. 64, por lo que, por un lado, la velocidad rápida del sitio web favorece la mejora de la experiencia del usuario. Por otro lado, el blog del administrador de Google dejó claro este año que la velocidad del sitio web es uno de los factores de clasificación y el uso de servidores extranjeros. para construir sitios chinos de Baidu La optimización y el tiempo insatisfactorio conducirán a un menor rastreo de páginas internas por parte de Baidu Spider. Guoping también lo mencionó antes en su artículo de blog: ¿Cómo afecta la velocidad de carga de la página web al efecto SEO? En un período de tiempo fijo, el tiempo total que tarda una araña en rastrear el sitio web es fijo. Si la velocidad de rastreo aumenta, la cantidad de páginas rastreadas será mayor y viceversa.
Bien, comencemos con el texto principal En la pregunta 2 del artículo anterior "Resultados experimentales del rastreo de páginas estáticas por arañas y la activación de la compresión gzip", adiviné cómo se guarda la versión comprimida de las páginas estáticas gzip en el servidor. Después de estar confundido durante mucho tiempo, descubrí que la razón final de los diferentes resultados de gzip devueltos por los dos hosts era la versión de iis en lugar de la configuración de la carpeta de caché que supuse era demasiado pequeña.
De hecho, iis7 tiene una actualización mayor que iis6 en compresión estática. En IIS6, la compresión estática se realiza en un subproceso diferente, por lo que después de recibir una solicitud HTTP, la primera versión HTML enviada al navegador se descomprime y se iniciará IIS6. usar un hilo diferente para comprimir el archivo y almacenar la versión comprimida en la carpeta de caché del archivo comprimido durante mucho tiempo. En el pasado, es decir, en el servidor IIS6, una vez completada la compresión, para cualquier solicitud HTTP de la versión comprimida del archivo estático, IIS6 llamaba directamente a la versión comprimida desde la carpeta de caché y la devolvía al navegador.
Pero en IIS7, la compresión se realiza en el hilo principal y, para ahorrar el costo de la compresión, IIS7 no guarda versiones comprimidas a largo plazo de todas las solicitudes HTTP, sino solo archivos estáticos a los que los usuarios acceden con frecuencia. La primera vez que lo visité, no estaba comprimida. La versión comprimida se devolvió cuando la visité nuevamente en un corto período de tiempo, pero la versión sin comprimir se devolvió cuando la visité después de unos minutos. Aquí podemos entender que IIS7 en realidad no guarda la versión comprimida en la carpeta de caché, sino que solo la guarda en la memoria del servidor, o guarda temporalmente la versión comprimida en la carpeta de caché y la elimina después de un tiempo.
El método para que IIS7 defina a qué archivos se accede con frecuencia y cumple con los estándares de compresión son las dos propiedades siguientes en system.webServer/serverRuntime, frecuentHitThreshold y frecuentHitTimePeriod. Si IIS recibe acceso a un archivo estático que excede el umbral de FrecuenteHitThreshold dentro del período de FrecuenteHitTimePeriod, IIS7 comprimirá el archivo estático como IIS6 y almacenará la versión comprimida en la carpeta de caché del archivo comprimido durante mucho tiempo. Si ya existe una versión almacenada en caché del archivo en la carpeta de caché cuando un usuario accede a un archivo en el sitio web, IIS7 ya no juzgará la lógica de frecuentHitThreshhold y devolverá directamente la versión comprimida al navegador.
De hecho, esta configuración es muy dolorosa, pero la respuesta oficial de Microsoft es que puede usarse para mejorar el rendimiento del servidor. . . Entonces, si desea que IIS7 pueda comprimirse como IIS6, existen dos soluciones. Por supuesto, ambas modifican los valores de frecuentHitThreshold y frecuentHitTimePeriod:
El primero es agregar el siguiente contenido a web.config, ajustar el umbral de hito frecuente a 1 y ajustar el período de hito frecuente a 10 minutos.
<sistema.servidorweb>
<tiempo de ejecución del servidor habilitado = verdadero
umbral de impacto frecuente = 1
frecuenteHitTimePeriod=00:10:00/>
</sistema.servidorweb>
El segundo método es abrir %windir%/system32/inetsrv/appcmd.exe, luego ingresar la siguiente cadena de comando en la interfaz de línea de comando y luego presionar Enter
establecer configuración -sección:system.webServer/serverRuntime -frequentHitThreshold:1
Los funcionarios de Microsoft sugieren que un enfoque menos radical no es reducir el umbral de hit frecuente sino aumentar el período de hit time, que es más moderado para el rendimiento del servidor. Lo que quiero mencionar aquí es que para los amigos que tienen VPS, se recomienda configurarlo manualmente. Si los usuarios de host virtual pueden configurarlo depende del proveedor de servicios. Desafortunadamente, no puedo cambiarlo. Todos, pruébenlo.