Azure 캐시 서비스에 연결하는 데 약 3.3 초 걸립니다.

Question

아직 개발중인 프로젝트에서 우리는 ASP.NET Web API 서비스에 액세스 할 때 갑작스러운 지연을 발견했습니다. 멋진 Mini Profiler을 사용하여 이러한 지연은 Azure 데이터 캐시 (미리보기) 서비스에 대한 연결이 끊어지고 다시 설정되어야 할 때 발생합니다. 이 프로세스는 약 3.3 초가 걸립니다. 다시 연결하면 캐시에서 개체를 가져 오는 데 1.4 밀리 초가 걸립니다.

maxConnectionsToServer를 1에서 20으로 늘리면 다른 것을 알았습니다. 웹 API에 1 ~ 2 분 동안 요청하지 않으면 (대개 연결이 끊어 질 때), 다음 20 개의 요청이 3.3 초 동안 지연됩니다 (연결 풀링이 작동하는 방식입니다). 풀에서 연결 제거).

웹 API와 캐싱 서비스 모두 동부 미국 지역에서 호스팅되며 로컬 캐시를 사용하지 않도록 설정하고 SSL을 사용하지 않도록 설정하면 자동 검색이 사용됩니다.

Azure 캐시가 여전히 미리보기에 있기 때문에 뭔가 잘못되었거나 궁금합니다.

모든 정보는 가치가 있습니다.

감사합니다.

Answer 1

공유 캐시가 비활성 상태로 인해 오프로드되는 것 같습니다. 이를 테스트하는 한 가지 방법은 기존 서비스에 In-Role Cache (사용 가능한 경우)를 추가하고 캐시 사용을이 새 캐시로 스왑하는 것입니다. 역할 내 캐시는 here으로 설명됩니다.

캐시를 공유 오퍼링에서 제거한 후에는 유휴 시간 제한을 위해 1-2 분 정도 기다렸다가 연결을 재 시도하십시오. 지연 시간은 없어야합니다.

문제를 격리 한 후 공유 캐시 옵션을 사용한다고 가정 할 때, 현재 알고있는 유일한 해결 방법은 주기적으로 캐시를 핑 상태로 유지하는 백그라운드 작업을 실행하는 것입니다.

전체 웹 역할을 실행하는 경우 응용 프로그램 시작시 백그라운드 작업을 시작할 수 있습니다.
모바일 서비스를 통해 배포하는 경우 예약 된 작업을 통해 "ping"을 실행할 수 있습니다. 여기에서 실행할 수있는 유일한 문제는 예약 된 작업의 최소 시간은 1 분이며 캐시를 100 % 유지하는 데 충분히 공격적이지 않을 수 있습니다.

Answer 2

내가보기에 당신에게 아무 것도 잘못한 것을 가리키는 내용은 없습니다. Azure가 진정으로 캐시 연결을 빠르게 실행하는 데 문제가있을 수 있습니다. 몇 가지 모범 사례 문서 및 MSDN 게시물에 따르면 활성 연결에 대한 장애 조치를 허용하기 위해 캐시에 대한 연결 수를 늘리려는 것이므로 구성 변경으로 효과적으로 수행 할 수 있습니다.

캐시 접근자가 정적 개체 (다른 MSDN 권장 사항)인지 확인하고 이것이 길게 나타날 수도 있지만 개체 만료에 슬라이딩 창 옵션을 사용하여 개체 저장소에 대한 카운트 다운을 알려줄뿐만 아니라 다시 설정하지만 캐시 서비스에 연결을 재설정하라는 메시지도 표시합니다.