변환 된 XML의 메모리 내 캐싱의 단점?

Question

저는 데이터베이스에서 XML "구성 요소"를 지속적으로 검색 한 다음 XSLT를 사용하여 XHTML로 변환하는 웹 응용 프로그램을 작성하고 있습니다. 이러한 변형 중 일부는 자주 발생합니다 (예 : '사이드 바 탐색'구성 요소가 동일한 XML에 대해 나가서 사이드 바를 특징으로하는 모든 페이지에서 동일한 XSL 변환을 수행함). 따라서 속도를 높이기 위해 일부 캐싱을 구현하기 시작했습니다.

현재 솔루션에서 각 구성 요소가 변환을 시도하기 전에 구성 요소는 정적 CacheManager 개체로 검사하여 변환 된 XML의 캐시 된 버전이 있는지 확인합니다. 그렇다면 구성 요소가이를 출력합니다. 그렇지 않은 경우 구성 요소는 변환을 수행 한 후 변환 된 XML을 CacheManager 객체와 함께 저장합니다.

CacheManager 개체는 캐시 된 변환 된 XML의 메모리 내장 저장소를 유지합니다 (정확하게는 Dictionary). 내 로컬 개발 환경에서이 작업은 아름답게 작동하지만이 방법은 확장 성이 뛰어난 솔루션이 아닐 수도 있습니다.

이러한 데이터를 메모리에 저장하는 잠재적 인 위험은 무엇입니까? 이와 같이 메모리 내 데이터 구조에 저장할 수있는 데이터의 양을 제한해야합니까? 이 캐싱 유형에 대해 다른 데이터 저장소를 사용해야합니까?

Answer 1

의심 할 여지가 있지만 잠재적으로 캐시의 메모리 사용량이 높아질 수 있습니다. 메모리 압력이 높아지면 거의 사용되지 않는 항목이 캐시에서 "만료"되는 시스템을 구현할 수 있습니다. Microsoft의 Caching Application Block은 즉시 필요한 모든 것을 구현합니다.

발생할 수있는 또 다른 잠재적 인 문제는 캐시를 통해 필요한 것을 찾기 위해 드는 비용입니다. 어떤 시점에서 캐시를 살펴 보는 대신 필요한 것을 생성하는 것이 더 빠를 수 있습니다. 우리는 매우 큰 캐시와 매우 저렴한 연산과 관련된 최소한 하나의 정확한 시나리오에서이를 실행했습니다. 가능성은 낮지 만 일어날 수 있습니다.

Answer 2

일반적인 chache 구현을 찾아야합니다. 나는 C#을 사용하지 않는다. 그래서 나는 당신의 언어로 어떤 해결책을 알지 못한다. 자바에서는 EHCache를 추천했을 것입니다.

처음에는 캐싱이 훨씬 더 어려워 보입니다. 그래서 다른 사람들이하는 일에 의존하는 것이 좋습니다. 일부는 당신이 어떤 시점에서 실행됩니다 동시성, 캐시 무효화, 시간, 캐시 캐싱, 캐시 관리 (통계, 캐시 지우기 ...), 디스크 오버플로, 분산 캐싱, 라이브 캐시 시간입니다.

캐시 모니터링이 필수입니다. 캐싱 전략을 실제적으로 잘 수행하고 있는지 확인해야합니다 (캐시 적중 횟수/캐시 누락, 사용 된 캐시의 비율 등). 캐시를 더 잘 모니터 할 수 있도록 여러 영역에서 캐시를 나누어야합니다 용법.

변환 후 XML을 캐시하는 한, 객체 트리가 아닌 String 표현을 저장해야합니다. 어쨌든 String으로 출력하고 있기 때문에 캐시 이후에는 변환이 덜 한 것입니다. String 표현이 공간을 적게 차지할 가능성이 있습니다. (항상 그렇듯이 그것을 측정합니다.)

Answer 3

캐싱을 수행 할 수 있지만 사전에 참조 값 (uri) 만 유지하고 실제 변환 된 XML을 디스크에 저장합니다. 이것은 아마도 데이터베이스에서 값을 검색하고 변환을 다시 수행하는 것보다 빠를 것입니다.이 모든 것을 메모리에 저장하는 것보다 느리지 만 메모리에서이 모든 캐시 된 데이터를 처음부터 가지게되는 문제를 해결합니다.이것은 또한 변형 된 XML 문서가 재활용/재설정을 통해 살아남을 수는 있지만 사전을 다시 작성해야하고 디스크 캐시에서 제거해야하는 "만료 된"문서에 대해서도 고려해야합니다.

그냥 생각해 ..