위기 상황에 대비하여 계획을 세우고 있습니다. (마지막으로 하루에 4k 명에서 1.3M으로 이동했습니다.) Azure AppFabric 캐시의 하단에는 상당히 낮은 동시 연결이 있습니다. 한계동시 Azure Appfabric 캐시 연결 추정
128Mb & 예를 들어 256Mb 캐시 = 10 동시 연결.
webrole 세션 상태를 위해 캐시를 사용하고 있습니다. 그러나 제한된 상황 (라이브 사이트는 지난 달 0.03MB를 정점으로 최고 기록을 세웠습니다!)으로 최대 연결 수를 계산하려면 어떻게해야합니까? 내가 가리키는 서버의 수와 동등한가? CPU의 수는?
아직 시도하지는 않았지만 캐시 크기를 조정하면 24 시간 운영되는 것처럼 보입니다. 비상 사태에 대비하여 충분히 반응하지 않습니다.
초기 캐시 크기를 선택하고 눈금을 조정하는 데 도움이되는 몇 가지 지침 바로 뒤에 있습니다.
캐시에 연결해야하는 수는 기본적으로 사용자가 가지고있는 DataCacheFactory 인스턴스의 수입니다. 이러한 이유로 여러분이 할 수있는 것들을 거의 가지고 있지 않는 것이 좋습니다. DataCacheFactory을 초기화 한 Azure 인스턴스가 멈출 때 인스턴스를 처리해야 할 때이 인스턴스가 서비스에 대해 열려있는 연결을 정리하는 데 도움이되도록해야합니다.
그러나 세션 공급자로 캐시를 사용한다고하셨습니다. 이렇게하면 각 역할 인스턴스에 대해 자체 DataCacheFactory이 생성됩니다. 기본적으로 역할마다 하나의 연결입니다. 세션 공급자는 사용하지 않는 연결을 정리하는 방법이 조금 느슨한 것처럼 보였으므로 연결 수를 과도하게 제공하는 것이 가장 좋습니다.
다른 하나는 캐시의 "트랜잭션 시간당"제한입니다. 페이지에 대한 모든 요청이 세션 정보에 액세스해야하는 경우 이는 한 시간 내에 제공 할 수있는 페이지 요청 수입니다.
캐시 크기 조정은 실제로 매우 빠릅니다. 보통 1 분 정도 소요됩니다. 그러나 24 시간마다 한 번만 변경할 수 있습니다. 따라서로드를 증가 시키면 캐시를 크게 만들 수 있지만 증가 된 캐시의로드가 너무 많은 경우 24 시간이 지나면 다시 변경해야합니다. 따라서 캐시를 처음으로 크기를 조정하고 다음 날 다시 축소 할 때 캐시를 훨씬 더 크게 만드는 것이 좋습니다.
편집 : 당신을 통해 캐시를 구성하지 않는 경우 기본적으로 설정되어 이 정보에는 writting 당시 정확한 동안, 11 월 2011이 SDK에 (1.6) 업데이트가 발표했다 캐시 연결 풀링 암호. 따라서 정적 인 하나만있는 것이 중요하지 않으며 세션 및 응용 프로그램 데이터 모두에 동일한 연결 정보를 사용하려는 경우 모두 하나의 연결이 될 수 있습니다. 더 details can be found on MSDN.
세션 공급자를 사용하면 각 페이지가 캐시에 종속되어 캐시 히트가 발생합니까? 그렇지 않은 경우 페이지의 하위 집합입니다. 무대 뒤에서 어떤 일이 벌어 지는지 알고 싶습니까? 시간당 거래는 가시적으로 측정되지 않습니다. – Andiih
기본적으로 예입니다. 그 전화에 대해 세션을 사용하지 않도록 설정하지 않으면 (이것은 ajax 호출을 포함하고 CSS 및 이미지와 같은 리소스에 대한 호출이라고 생각하지만 다른 사람이 대답 할 수있는 또 다른 질문입니다). 일반적으로 거래는 어디서나 볼 수 없습니다. 분명히 App Fabric Application의 일부로 그것들을 볼 수는 있겠지만, 나는 그것만으로 실험하지 않았습니다. – knightpfhor
"thats another question"... 네, 지금은 :-) http : // stackoverflow입니다.com/questions/7977963/when-using-azure-appfabric-cache-as-a-session-state-provider-what-causes-a-trans – Andiih