AzureWebサイトは静的JS / CSSの提供に時間がかかりますが、バイナリではありません
静的なJSファイルとCSSファイルを提供するのに非常に遅いが、バイナリを提供するのは完全に問題ないように見えるAzure Webサイト/ Webアプリがあります。
問題をテストするために、2つの30MBファイルをアップロードしました。1つはbig.jsで、もう1つはbig.rarです。運が良ければ、JSファイルは約100KB /秒でダウンロードされます。 RARファイルは約4,000KB /秒でダウンロードされます。結果は非常に一貫しています。
Fiddlerをチェックインしましたが、どちらの場合もgzip圧縮が発生しています。予想どおり、JSファイルはMIMEタイプapplication/x-javascriptで送信されていますが、RARファイルはapplication/octet-streamとして提供されています。
私はこれを理解するのに苦労しています-なぜIISあるタイプの静的コンテンツを別のタイプよりもはるかに遅く提供するのでしょうか？
この問題が発生し、Azureサポートチームの助けを借りてこれを解決することができました。問題は、遅いファイルがTransferEncoding：Chunckedを使用することでした。彼らは、この問題を回避するために静的圧縮を強制することを提案しました。
<system.webServer>に以下を追加する必要がありました。
<serverRuntime enabled="true" frequentHitThreshold="1" frequentHitTimePeriod="00:00:20" />
John Tsengの答えを詳しく説明するには：（ ここ から）
前に見たように、IIS 7は静的ファイルの圧縮バージョンをキャッシュします。したがって、圧縮バージョンがすでにキャッシュにある静的ファイルの要求が到着した場合、それは必要ありません。再び圧縮されます。
しかし、キャッシュに圧縮バージョンがない場合はどうなりますか？ IIS 7は、ファイルをすぐに圧縮してキャッシュに入れますか？答えは「はい」ですが、ファイルが頻繁に要求されている場合に限ります。要求頻度が低いファイルを圧縮しないことにより、 IIS 7は、CPU使用率とキャッシュスペースを節約します。
デフォルトでは、ファイルが10秒に2回以上要求された場合、ファイルは頻繁に要求されたと見なされます。
したがって、ユーザーに非圧縮バージョンのjavascriptファイルが提供される理由は、圧縮のデフォルトのしきい値を満たしていないためです。つまり、javascriptファイルは10秒以内に2回要求されませんでした。
これを制御するには、圧縮を制御する<serverRuntime>要素で変更する必要のある属性が1つあります：frequentHitThreshold。一度要求されたときにファイルを圧縮するには、<serverRuntime>要素を次のように変更します。
<serverRuntime enabled="true" frequentHitThreshold="1" />
これは、提供されているjavascriptファイルが多数あり、ユーザーが頻繁にいる場合、CPUパフォーマンスにわずかに影響しますが、CPUにこれらのファイルの圧縮から影響を与えるほど頻繁にユーザーがいる場合は、既に圧縮されてキャッシュされています。
IIS 8.5の問題であり、Azure固有の問題だけではないようです。
現在、アプリサービス Windows Server 2016へのアップグレードは完了しているように見えます この回避策は必要ありません。