Azure 웹사이트는 정적 JS/CSS를 처리하는 속도가 느리지만 바이너리가 아니다.

Azure 웹사이트는 정적 JS/CSS를 처리하는 속도가 느리지만 바이너리가 아니다.

Azure Web 사이트/Web 앱은 정적 JS 및 CSS 파일 처리에는 매우 느리지만 바이너리 처리에는 완벽하게 문제가 없는 것 같습니다.

문제를 테스트하기 위해 30MB 파일 2개를 업로드했습니다.하나는 big.js이고 다른 하나는 big.rar입니다.JS 파일은 운이 좋으면 100KB/s 정도로 다운로드가 됩니다.RAR 파일은 약 4,000KB/s로 다운로드 됩니다.결과는 매우 일관성이 있다.

Fiddler에 체크인을 했는데 두 경우 모두 gzip 압축이 발생하고 있습니다.예상대로 JS 파일은 MIME 타입의 application/x-javascript와 함께 전송되며 RAR 파일은 application/octet-stream으로 제공됩니다.

IIS가 다른 정적 콘텐츠보다 훨씬 느린 이유는 무엇입니까?

우리는 이 문제를 겪었고, Azure 지원팀의 도움으로 이 문제를 해결할 수 있었습니다.문제는 느린 파일이 Transfer Encoding을 사용한다는 것입니다.막혔어.그들은 이 문제를 피하기 위해 정적 압축을 강제할 것을 제안했습니다.

다음 .<system.webServer>:

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

쩡현(s ts)의 답변에 대해 자세히 설명하겠습니다. (여기서)

앞에서 보셨듯이 IIS 7은 정적 파일의 압축 버전을 캐시합니다.따라서 압축 버전이 이미 캐시에 있는 정적 파일에 대한 요청이 도착하면 다시 압축할 필요가 없습니다.

그러나 캐시에 압축 버전이 없으면 어떻게 됩니까?그러면 IIS 7은 파일을 즉시 압축하여 캐시에 저장합니까?답변은 "예"입니다. 단, 파일이 자주 요청되는 경우에만 해당됩니다.IIS 7 에서는, 요구가 빈발하는 파일을 압축하지 않기 때문에, CPU 사용량과 캐시 용량을 절약할 수 있습니다.

기본적으로는 파일은 10초당 2회 이상 요청될 경우 자주 요청되는 것으로 간주됩니다.

따라서 사용자에게 압축되지 않은 버전의 Javascript 파일이 제공되는 이유는 압축된 기본 임계값을 충족하지 못했기 때문입니다. 즉, javascript 파일이 10초 이내에 2번 요청되지 않았습니다.

Attribute 1에서 해야 할 있습니다.<serverRuntime> " " " " " " : "frequentHitThreshold파일이 한 번 요청되었을 때 압축되도록 하려면 다음 명령을 변경하십시오.<serverRuntime>다음과 같은 요소:

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

많은 javascript 파일이 서비스되고 있고 사용자가 자주 있는 경우 CPU 퍼포먼스에 약간의 영향을 미칩니다.그러나 이러한 파일을 압축함으로써 CPU에 영향을 줄 수 있을 만큼 사용자가 자주 있는 경우에는 이미 압축되어 캐시되어 있습니다.

Azure만의 문제가 아니라 IIS 8.5의 문제인 것 같습니다.

이제 Windows Server 2016으로의 App 서비스 업그레이드가 완료된 것으로 보이며 이 해결 방법은 필요하지 않습니다.

언급URL : https://stackoverflow.com/questions/29373297/azure-website-slow-to-serve-static-js-css-but-not-binary