私の質問はこれと似ていますが、私の問題は Windows Azure 共有キャッシュに関するものであり、新しい Windows Azure キャッシュに関するものではありません。
本当に奇妙な問題です。共有の Azure キャッシュをセットアップし、1 つのホストされたクラウド サービスで作業しています。アプリは と の両方に使用していsessionState
ますcaching/outputCache
。そのアプリには遅延の問題はまったくありません。これは、共有キャッシュと同様に、米国中北部に展開されます。
また、2 つ目のホステッド サービスもあり、これも米国中北部にデプロイされています。この 2 番目のアプリは、同じ共有キャッシュを使用するように構成しました。奇妙な点は次のとおりです。web.config のセクションを構成<caching>/<outputCache>
して共有キャッシュを指すようにすると、すべての (MVC4) Web 要求が約 5 ~ 6 秒遅くなります。この web.config セクションをコメントアウトすると、Web リクエストが大幅に高速化されます (~100 ミリ秒)。
私はまだ sessionState に同じ共有キャッシュを使用しており、それは高速であるため、キャッシュ接続自体の遅延の問題のようには見えません。また、MVC4 アクションのいずれも OutputCacheAttribute を使用していないことに注意してください。レイテンシーは、outputCache セクションを web.config に追加して再デプロイするだけで再現できます。
どちらのアプリも同じデータセンター リージョンにあり、同じ VM サイズ、インスタンス、および osFamilies を使用しています。私が考えることができるそれらの唯一の違いは、最初のもの (遅延の問題がないもの) が MVC3 アプリであるのに対し、2 つ目は MVC4 アプリであることです。
Windows Azure 共有キャッシュを指す caching/outputCache 構成セクションを追加するだけで、すべての MVC4 要求が遅くなるのはなぜですか?
更新 1:
Azure にデプロイしなくても、この問題を再現できるようになりました。問題の共有キャッシュをセッションと outputCache の両方に使用するように、ローカルの VS / IIS Express インストールをセットアップしました。この web.config 設定を変更するまで、1 秒未満の応答が返されていました。
<compilation debug="false" ... <!-- changed this from true to false
system.web セクションのデバッグ フックをオフにすると、応答時間が 5 ~ 6 秒になり始めました (再現)。これは、MVC4 のバンドルおよび縮小機能の問題でしょうか? デバッグ コンパイルをオフにすると応答レイテンシが最大 10 倍増加するのは非常に奇妙です.....
更新 2:
MiniProfiler は、はい、この遅延の 4 秒以上は、MVC _Layout.cshtml の @Scripts.Render("~/bundles/mybundle") の 1 つから来ていると言っています。web.config の outputCache 設定が、バンドルされたスクリプトのリリース モード レンダリングに影響しているようです。しかし、なぜですか?