muestra imagenes habilitar carga iis azure azure-web-sites static-content

iis - imagenes - El sitio web de Azure es lento para servir JS/CSS estático pero no es binario



iis no carga css (3)

Para elaborar sobre la respuesta de John Tseng: (de here )

Como viste anteriormente, IIS 7 almacena en caché las versiones comprimidas de los archivos estáticos. Por lo tanto, si llega una solicitud de un archivo estático cuya versión comprimida ya está en la memoria caché, no es necesario volver a comprimirla.

Pero, ¿qué pasa si no hay una versión comprimida en el caché? ¿IIS 7 comprimirá el archivo de inmediato y lo colocará en el caché? La respuesta es sí, pero solo si el archivo se solicita con frecuencia. Al no comprimir archivos que solo se solicitan con poca frecuencia, IIS 7 ahorra el uso de la CPU y el espacio de la memoria caché.

De forma predeterminada, se considera que un archivo se solicita con frecuencia si se solicita dos o más veces cada 10 segundos.

Por lo tanto, la razón por la que sus usuarios reciben una versión no comprimida del archivo javascript es porque no cumplió con el umbral predeterminado para ser comprimido; en otras palabras, el archivo javascript no fue solicitado 2 veces en 10 segundos.

Para controlar esto, hay un atributo que debemos cambiar en el elemento <serverRuntime> , que controla la compresión: frequentHitThreshold . Para que su archivo se comprima cuando se solicita una vez, cambie su elemento <serverRuntime> para que se vea así:

<serverRuntime enabled="true" frequentHitThreshold="1" />

Esto tendrá un impacto leve en el rendimiento de su CPU si tiene muchos archivos javascript que se están procesando y tiene usuarios con bastante frecuencia, pero es probable que si tiene usuarios lo suficientemente fuertes como para afectar la CPU al comprimir estos archivos, ¡ya estén comprimidos y en caché!

Tengo una aplicación web / sitio web de Azure que es increíblemente lenta para servir archivos estáticos JS y CSS, pero parece perfectamente útil para servir binarios.

Para probar el problema, cargué dos archivos de 30MB , uno big.js y el otro big.rar . El archivo JS se descarga a aproximadamente 100 kB / s si tengo suerte. El archivo RAR se descarga a aproximadamente 4.000 KB / s. Los resultados son extremadamente consistentes.

Revisé Fiddler y la compresión de gzip está ocurriendo en ambos casos. Como era de esperar, el archivo JS se está enviando con la aplicación de tipo MIME / x-javascript, mientras que el archivo RAR se está sirviendo como application / octet-stream .

Estoy luchando por comprender esto: ¿por qué IIS serviría un tipo de contenido estático mucho más lento que otro?



Tuvimos este problema y pudimos resolverlo con la ayuda del equipo de asistencia de Azure. El problema era que los archivos lentos usarían TransferEncoding: Chuncked. Sugirieron que forzamos la compresión estática para evitar este problema.

Tuvimos que agregar lo siguiente a <system.webServer> :

<serverRuntime enabled="true" frequentHitThreshold="1" frequentHitTimePeriod="00:00:20" />