Programing

MemoryCache의 여러 인스턴스 사용

lottogame 2020. 11. 9. 07:37
반응형

MemoryCache의 여러 인스턴스 사용


System.Runtime.Caching네임 스페이스를 사용하여 애플리케이션에 캐싱 기능을 추가하고 싶고 , 여러 위치와 다른 컨텍스트에서 캐싱을 사용하고 싶을 것입니다. 이를 위해 여러 MemoryCache 인스턴스를 사용하려고합니다.

그러나 여기 에서 MemoryCache 인스턴스를 두 개 이상 사용하지 않는 것이 좋습니다.

MemoryCache는 단일 항목이 아니지만 몇 개 또는 잠재적으로 하나의 MemoryCache 인스턴스 만 만들어야하며 항목을 캐시하는 코드는 이러한 인스턴스를 사용해야합니다.

여러 MemoryCache 인스턴스가 내 애플리케이션에 어떤 영향을 미칩니 까? 응용 프로그램에서 여러 캐시를 사용하는 것이 매우 일반적인 시나리오라고 생각하기 때문에 이런 종류의 이상하다고 생각합니다.

편집 : 더 구체적으로, 각 인스턴스에 대해 캐시를 유지해야하는 클래스가 있습니다. 사용을 피하고 MemoryCache다른 캐싱 솔루션을 찾아야합니까? MemoryCache이 상황에서 사용 하는 것은 나쁜 것으로 간주되며, 그렇다면 그 이유는 무엇입니까?


나는 최근에 이것을 직접 겪었습니다. 메모리 내 캐시가 프로세스에 따라 다르다는 것을 고려하면 (웹 사이트의 여러 인스턴스 나 네이티브 비즈니스 앱 또는 여러 서버에서 공유되지 않음) MemoryCache코드 구성 이유 (다른 방식으로 달성 할 수 있음)를 제외하고는 여러 인스턴스 를 갖는 것이 실제로 이점이 없습니다 .

메모리 캐시는 대부분 메모리 관리 기능으로 인해 단독으로 사용됩니다. 약간의 오버 헤드가있는 성능 카운터 외에도 MemoryCache는 할당 된 메모리가 부족할 때 항목을 만료시킬 수 있습니다.

캐시의 현재 인스턴스가 CacheMemoryLimit 속성에서 설정 한 메모리 제한을 초과하면 캐시 구현이 캐시 항목을 제거합니다. 애플리케이션의 각 캐시 인스턴스는 CacheMemoryLimit 속성에 지정된 메모리 양을 사용할 수 있습니다.

에서 MemoryCache.CacheMemoryLimit 재산권

MemoryCache 인스턴스를 하나만 사용하면 전체 애플리케이션 인스턴스에이 메모리 관리를 효율적으로 적용 할 수 있습니다. 전체 애플리케이션에서 중요도가 가장 낮은 항목을 만료합니다. 이를 통해 하드웨어 성능을 초과하지 않고 최대 메모리 사용을 보장합니다. 하나의 MemoryCache의 범위 (예 : 클래스의 인스턴스 하나)를 제한함으로써 더 이상 응용 프로그램의 메모리를 효과적으로 관리 할 수 ​​없습니다 (모든 것을 "볼"수 없으므로). 이러한 캐시가 모두 "바쁜"경우 메모리 관리에 더 많은 시간이 걸리고 거의 효율적이지 않습니다.

이것은 전용 서버의 사치가없는 애플리케이션에서 특히 민감합니다. 150MB RAM (일반적으로 저렴한 $ 10 / 월 호스팅) 만 할당 된 공유 서버에서 앱을 실행한다고 가정 해보십시오.이를 초과하지 않고 최대로 사용하려면 캐시에 의존해야합니다. 이 메모리 사용량을 초과하면 앱 풀이 재활용되고 앱의 메모리 캐시가 모두 손실됩니다! (일반적인 저렴한 호스팅 관행) 일부 공유 회사 서버에서 사내에서 호스팅되는 비 웹 앱에도 동일하게 적용될 수 있습니다. 똑같은 거래, 당신은 그 컴퓨터의 모든 메모리를 잡아 먹지 말고 다른 업무용 앱과 평화롭게 공존하라는 지시를 받았습니다.

메모리 제한, 앱 풀 재활용, 캐시 손실은 웹 앱의 일반적인 "아킬레스 건"입니다. 앱이 가장 바쁠 때 메모리 할당 초과, 모든 캐시 항목 손실 및 애초에 캐시 된 항목을 다시 가져 오는 대부분의 작업으로 인해 가장 자주 재설정됩니다. 즉, 앱이 실제로 얻는 대신 최대 부하에서 성능을 잃습니다.

MemoryCache가 System.Web.Caching.Cache 구현의 웹이 아닌 특정 버전이라는 것을 알고 있지만 이것은 캐시 구현의 논리를 보여줍니다. 하드웨어를 독점적으로 사용하지 않는 경우 웹이 아닌 프로젝트에도 동일한 논리가 적용될 수 있습니다. 캐시가 시스템이 페이지 파일 스왑을 시작하도록 강제하면 캐시가 디스크에 캐시하는 것보다 더 이상 빠르지 않습니다. 제한이 2GB 정도이더라도 항상 어딘가에 제한을 원할 것입니다.

제 경우에는 이것에 대해 읽은 후 앱에서 하나의 '공용 정적 MemoryCache'를 사용하도록 전환하고 캐시 키로 캐시 된 항목을 분리했습니다. 예를 들어 인스턴스별로 캐시하려는 경우 "instance- {instanceId} -resourceName- {resourceId}"와 같은 캐시 키를 가질 수 있습니다. 캐시 항목의 이름 간격으로 생각하십시오.

도움이 되었기를 바랍니다.


나도 여러 개를 사용합니다. 일반적으로 유형 당 하나씩.

를 보면 이벤트에 MemoryCache연결되고 AppDomain성능 카운터가 유지 되는 것을 알 수 있습니다 . 두 개 이상 (예 : CPU, 카운터 및 메모리)을 사용하여 리소스 측면에서 오버 헤드가 발생한다고 생각하므로 권장하지 않습니다.

참고 URL : https://stackoverflow.com/questions/8463962/using-multiple-instances-of-memorycache

반응형