내 질문은 this one과 비슷하지만 최신 Windows Azure 캐싱이 아닌 Windows Azure Shared Caching 문제가 있습니다.Azure Shared Cache를 가리키는 Web outputCache 구성 섹션이 모든 요청을 느리게하는 이유는 무엇입니까?
정말 이상한 문제입니다. 공유 azure 캐시를 설정하고 하나의 호스팅 된 클라우드 서비스에서 작업하고 있습니다. 앱에서 sessionState
및 caching/outputCache
에 모두 사용 중입니다. 이 앱에는 대기 시간 문제가 전혀 없습니다. 공유 캐시가있는 것처럼 North Central US에 배포됩니다.
나는 또한 미국 중북부에 배포되는 두 번째 호스팅 서비스를 운영하고 있습니다. 두 번째 앱이 동일한 공유 캐시를 사용하도록 구성했습니다. 이상한 점은 다음과 같습니다. web.config의 <caching>/<outputCache>
섹션을 공유 캐시를 가리 키도록 구성하면 모든 단일 (MVC4) 웹 요청이 약 5-6 초로 느려집니다. 이 web.config 섹션을 주석 처리하면 웹 요청이 훨씬 빠릅니다 (~ 100 밀리 초).
캐시 연결 자체에 대기 시간 문제가있는 것 같지 않습니다. 세션 상태에 대해 여전히 동일한 공유 캐시를 사용하고 있으므로 빠릅니다. 또한 MVC4 작업 중 OutputCacheAttribute를 사용하는 작업이 하나도 없습니다. 대기 시간은 단순히 outputCache 섹션을 web.config에 추가하고 재배포하여 재현 할 수 있습니다.
두 응용 프로그램은 동일한 vm 크기, 인스턴스 및 osFamilies를 사용하여 동일한 데이터 센터 영역에 있습니다. 내가 생각할 수있는 유일한 차이점은 대기 시간 문제가없는 첫 번째 MVC3 앱이며 두 번째 MVC4 앱입니다.
Windows Azure Shared Cache에서 가리키는 캐싱/출력 캐시 구성 섹션을 추가하면 왜 모든 MVC4 요청이 느려 집니까?
업데이트 1 :
은 지금 푸른에 배포하지 않고이 문제를 재현 할 수 있어요. 세션과 outputCache 모두에 문제가되는 공유 캐시를 사용하기 위해 로컬 VS/IIS Express를 설치합니다. system.web 섹션에서 디버그 후크를 해제하면
<compilation debug="false" ... <!-- changed this from true to false
, 나는 (복제) 5-6초의 응답 시간을 받기 시작 :이 Web.config의 설정을 변경할 때까지 하위 두 번째 응답을 얻고 있었다. 이것이 MVC4의 번들 및 축소 기능에 문제가 될 수 있습니까? 디버그 컴파일을 해제하는 응답 지연 시간 ~ 10 배 .....
업데이트를 증가 시킨다는 것을 아주 이상한 2 :
MiniProfiler 말해되는 예,이 대기 시간이 4 초 이상 중 하나에서 오는 내 @ Scripts.Render ("~/bundles/mybundle")는 MVC _Layout.cshtml에 있습니다. web.config의 outputCache 설정이 번들 스크립트의 릴리스 모드 렌더링에 영향을주는 것 같습니다. 그러나 왜?
다시 한 번 감사의 말씀을 드리겠습니다. 현재 권장되는 해결 방법은 무엇입니까? 번들을 축소하고 최적화하고 하늘색 캐시 공급자를 생략해야합니까? 아니면 하늘색 캐시 공급자를 사용하고 번들 최적화를 사용 중지 하시겠습니까? 대답이 "의존적"이면 결정을 내리기 위해 어떤 종류의 임계 값 매개 변수를 사용해야합니까? – danludwig