Ehcache.xml 설정 자료

Ehcache


레퍼런스의 근원(Locality of Reference)

기존 전통적인 경제법칙으로 유명한 파레토의 법칙은 상위 20퍼센트가 매출액의 80퍼센트를 점한다는 법칙이다.
예를 들어 2000만원 하는 자동차를 80명이 사는 것보다 1억원대 차를 사는 20명이 회사에 더 소중한 고객이 된다는 이야기인데, 흔히 백화점에서 VIP고객은 깍듯이 하면서 일반 저가나 소량 구매자들은 등한시 하는 구조도 페라토의 법칙을 적용했다고 할 수 있다.

이에반해(per contra) 와이어드 매거진의 편집장 크리슨 앤더슨(Chris Anderson)이 말하는 
롱테일(The long tail) 법칙은 이를 뒤집은 "역-파레토의 법칙"으로, 실제 80퍼센트의 고객이 상위 20퍼센트의 고객 보다 더 많은 회사의 이익에 기여한다는 것이다,
사례를 보면, 대표적으로 구글을 꼽을 수 있는데, 대형 광고주 보다, 컨텐츠를 검색하는 사람들이 컨텐츠를 양산 해내고 광고를 보며 만들어낸 콘텐츠에 광고주가 되어 기업에 이익을 많이 주고 있다. 또한, 트위터에서 보듯, 원글자보다 리트윗이나 인용을 하여 개시하는 80%의 이용자가 더 많고, 기업에 더 이익이 된다.

각각의 법칙은 절대적인 법칙이 아니라, 상황과 환경에 따라 다르게 논리적 타성성을 지녔을 뿐이다. 

EhCache는 이런 롱테일 법칙을 바르게 이해하고 시스템에 효과적으로 적용 할 수 있는 조건이 갖추어졌을 때 효율이 발생한다.
현재 사용 중인 리소스의 80%가 이미 예전에 처음 누군가의 의해 사용되어 졌던 20%의 리소스를 다시 호출 해야 한다면,해당 캐쉬 모듈에는 적합할 수 있다는 논리다.
가령 공통코드를 매번 데이터베이스를 커넥션해서 쿼리한 결과를 뿌려줘야 한다면 얼마나 비효율 할까를 생각할때, 어차피 처음 한번만 불러와서 계속 사용하면 되지 않겠냐는 하는 생각은 누구나 할 수 있다.
그래서 대부분 세션에 넣거나 싱글톤 클래스에 담아 쓰게 마련이다. 만약 리소스의 변경이 아에 일어 나지 않는 다는 가정하에서 말이다.
실제, 고정된 static-resource 나 HTML 같은 고정 콘텐츠가 아니라면 매번 해당 모듈을 실행 시켜 결과를 처리하는 것보다 특정 조건하에 변경이 일어 날 경우에만 반응하여 갱신하거나, 일정 시간 경과 후 해당 리소스를  갱신 시켜준다는 상황이라면 EhCache를 적용 해 볼만 할것이다.

지침(LoadMap)

ehcache.xsd  파일을 XMLSpy로 열어 전체 로드맵을 본 모습 (ehcache.jpg)

상당히 복잡하다. 비록 점선으로 된 부분은 옵셔널이라 기본 디볼트 값이 정해 져 있기도 하다.
여기서 중요한 포인트는 현재 내 시스템에 적합한 시나리오가 어떤 것이 있는지 먼저 파악 해야 한다는 점이다.

다음은 간단한 샘플 예제들이다. (http://ehcache.org/ehcache.xml) 

sampleCache1
최대 10000개의 요소를 메모리에 저장 할 수 있으며 해당 요소들은 10분 간 유지 하다 5분 후 사라지게 한다. 
또한 10000개 이상이 요소가 늘어 난다면, OS에 설정된 임시 디렉토리의 디스크에 저장 해야 한다. 
     Sample cache named sampleCache1
    This cache contains a maximum in memory of 10000 elements, and will expire
    an element if it is idle for more than 5 minutes and lives for more than
    10 minutes.

    If there are more than 10000 elements it will overflow to the
    disk cache, which in this configuration will go to wherever java.io.tmp is
    defined on your system. On a standard Linux system this will be /tmp"
    
<cache name="sampleCache1" maxEntriesLocalHeap="10000" maxEntriesLocalDisk="1000" eternal="false" diskSpoolBufferSizeMB="20" timeToIdleSeconds="300" timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" transactionalMode="off">

  <persistence strategy="localTempSwap" />

  </cache>

sampleCache2
1000개의 요소를 메모리에 저장하되 느려터진 I/O 발생을 유발시키는 디스크에는 전혀 쓰기를 하지않는다.

(풍부한 메모리가 확보된 서버이기 때문에 속도가 상대적으로 빠른 메모리를 최대한 활용하기 위해서)
Sample cache named sampleCache2
    This cache has a maximum of 1000 elements in memory. There is no overflow to disk, so 1000
    is also the maximum cache size. Note that when a cache is eternal, timeToLive and
    timeToIdle are not used and do not need to be specified.
<cache name="sampleCache2" maxEntriesLocalHeap="1000" eternal="true" memoryStoreEvictionPolicy="FIFO" /> 

sampleCache3
메모리가 부족하여 느리긴 하지만, 모든 캐시를 메모리가 아닌 디스크에 기록 하도록 한다.
디스크의 기록된 메모리는 VM이 재시작 하기 전까지 유효 하도록 하며 10분 간격으로
해당 메모리에 만료된 캐시 정보를 지우도록 쓰레드가 동작한다.
    Sample cache named sampleCache3. This cache overflows to disk. The disk store is
    persistent between cache and VM restarts. The disk expiry thread interval is set to 10
    minutes, overriding the default of 2 minutes.

  <cache name="sampleCache3" maxEntriesLocalHeap="500" eternal="false" overflowToDisk="true" diskPersistent="true" timeToIdleSeconds="300" timeToLiveSeconds="600" diskExpiryThreadIntervalSeconds="1" memoryStoreEvictionPolicy="LFU" />

자세하 내용은 다음을 참조:  http://ehcache.org/apidocs/2.9/


<cache> 에 대한 어튜리브트를 간략히 설명 하자면, 
diskExpiryThreadIntervalSeconds: 디스크에 저장된 캐시들에 대해  만료된 항목를 제거하기 위한 쓰레드를 실행 할 주기 설정
diskSpoolBufferSizeMB: 디스크 캐시에 쓰기 모드로 들어갈때, 사용될 비동기 모드의 스폴 버퍼 크기 설정, OutOfMemory 에러가 발생 시 수치를 낮추도록 한다.
diskPersistent: VM이 재기동 할때 캐싱된 객체들을 디스크에 계속 유지 할지 여부
diskAccessStripes: 디스크 퍼포먼스를 조정하기 위한 스트라핑 설정
eternal: 시간설정에 대한 무시 설정 (boolean), true 면 모든 timeout 설정은 모두 무시 되고 Element에서 캐시가 삭제 되지 않음
maxElementsInMemory: 메모리에 캐싱 되어질 객체의 최대수
maxEntriesLocalHeap: 힙메모리 최대량
memoryStoreEvictionPolicy: 객체의 갯수가 설정된 maxElementsInMemory에 도달 했을 경우 메모리에서 객체들을 어떤게 제거 할지 에 대한 제거 알고리즘
     FIFO First In First Out. 
            Cache에 node를 추가할 경우 등록시간을 기록하여, 지정한 Cache size가 overflow가 발생할 경우에, 
            등록시간이 가장 빠른 node를 입력된 node로 변경하여 Cache에 관리한다.
     LFU Least Frequently Used. 
            가장 호출이 안된 node를 overflow 발생시 삭제하고, 새로 등록된 node를 등록하는 알고리즘으로, 
            Cache에 등록된 값을 호출할 때 count값과 위치를 함께 관리하여, overflow 발생할 때 
            count값이 제일적은 node를 삭제한다.
     LRU Least Recently Used. 
            가장 오랫동안 사용이 안된 node를 overflow발생시에 삭제하고, 
            새로 등록된 node를 등록하는 알고리즘으로, Cache에 등록된 값을 호출할 때 
            호출된 node 의 위치를 제일 앞으로 이동한다. overflow가 발생할 경우, 마지막 node를 삭제하여 관리한다.

clearOnFlush: flush() 메소드가 실행 될 때 메모리 캐시가 바로 살제 할지 여부, 기본적으로 true 이며 바로 삭제됨.
name: 캐시 이름
overflowToDisk: maxElementsInMemory 음계량에 가까우면 오버플로우되는 객체들을 디스크에 저장 할지 결정
timeToIdleSeconds: 다음 시간 동안 유휴상태(Idle) 후 갱신 할 지 설정(default: 0)
timeToLiveSeconds: 다음 갱신 하기 까지 캐쉬가 유지 되는 시간 (0이면 만료시간을 지정하지 않는다고 보고 유지 되지 않음, default: 0)
maxElementsOnDisk: 디스크 캐시에 저장 될 최대 객체의 수를 지정
maxEntriesLocalDisk: 로컬 디스크에 유지 될 최대 객체 수
maxEntriesInCache: Terracotta의 분산 캐시에서만 사용 가능하며, 클러스터링에 저장 할 수 있는 최대 캐시 수를 설정
transactionalMode: copyOnRead , copyOnWrite 시 트렉젝션 모드를 설정
statistics: JMX 통계정보 갱신 옵션
copyOnRead: 읽기때 캐시 요소를 복사 할 지 여부
copyOnWrite: 캐시 객체 쓸 경우 위한 복사 할지 여부
   - copyOnRead와 Write는 캐쉬로 받아온 객체에 수정이 일어나는 경우 사용한다.
   - 캐시된 객체에 수정이 일어나면 참조호출로 인해 그 뒤에 호출되는 모든 객체가 수정 영향이 중첩되어 발생하므로 주의 필요"
logging: 로깅 사용 여부
overflowToOffHeap: Off-heap 메모리 사용을 설정을 사용 할 수 있으며 JAVA의 GC에 영향을 주지 않는다. 엔터프라이즈 버전에서만 사용가능 하며,   maxEntriesLocalHeap 설정을 최소한 100 요소까지 권정하며 OffHeap를 사용하는 경우 성능이 저하될수 있음.
maxMemoryOffHeap: Off-heap 메모리 사용의 최대 량을 설정
maxBytesLocalHeap: 최대 로컬 힙메모리 사용량 설정, 1k, 1m, 1g 해당 옵션을 사용할 경우 maxEntriesLocalHeap 설정은 사용 할 수 없음.
maxBytesLocalOffHeap: 로컬 VM의 최대 offHeap 사용량을 설정 
maxBytesLocalDisk: maxBytesLocalHeap에 설정된 캐시 사용 이후에 대한 디스크 스토리지의 한계를 설정

링크 : http://egloos.zum.com/js7309/v/11143838