2012-08-17 4 views
1

EHcache를 사용하는 playframework 2를 사용하고 있습니다. 이제 API에는 Cache.setCache.get 밖에 없으므로 하나의 큰 캐시가 있다고 생각합니다.하나의 캐시 대 다수의 캐시

캐시가 여러 개있는 경우 더 효율적이지 않습니까? ip 주소에 대한 하나의 캐시, 사용자 이름에 대한 하나의 캐시 등.

나에게 장/단점을 줄 수 있습니까?

답변

2

Play의 캐시 개체의 목적은 일반 캐시 시스템을 사용하는 것입니다.

당신은 실제 캐시를 확장하고 특정 접두사를 사용하여 캐시를 전문으로 할 수 있습니다

class UserCache { 

    public static final String PREFIX = "UserCache"; 

    public static void set(String key, User value) { 

     Cache.set(PREFIX + key, value); 
    } 

    public static User get(String key) { 
     return (User)Cache.get(PREFIX + key); 

    } 


} 
+0

예 이미 비슷한 접근 방식을 사용했습니다. 그러나 캐시에 1000 개의 항목이 있다고 가정 해 봅시다. 그리고 우리는 특정 사용자를 찾아 봅니다. 사용자가 캐시에없는 경우 1000 회의 누락이 발생합니다. 우리가 사용자 만 가진 특정 캐시를 가지면 캐시는 예를 들어 100 개 항목 -> 성능이 훨씬 더 작을 것입니다. 아니면 내가 틀렸어? –

+0

이러한 종류의 숫자의 경우에는 차이가 거의 없습니다 (메모리 내 해시 맵 액세스). –

0

는 가장 일반적인 의미에서 캐싱을 고려하십시오. 일반적으로 캐시는 크기 제한으로 증가 할 수 있으며 그 이후에 항목은 마지막으로 액세스 한 시간을 기준으로 캐시에서 제거됩니다.

사과와 배 모두를 캐시하고 캐시에 20 개의 항목을 저장할 수있는 충분한 공간이 있다고 가정 해 보겠습니다. 사과를위한 하나의 캐시와 배를위한 또 다른 캐시로 나누면 훌륭하게 분할 된 것처럼 보입니다. 그러나 고객이 많은 사과를 사용하지만 배가 거의 없다면 사과 캐시가 빨리 가득 차게되어 결국 사용 된 사과는 사과 캐시에서 제거되고 그렇지 않은 배는 제거됩니다. 장시간 사용하면 배가 가득 차서 배 캐시에 머무를 수 있습니다.

사과 나 배를 저장할 수있는 캐시가 방금 있다면 가장 최근에 사용한 객체를 캐싱하므로 전체적으로 더 효율적일 수 있습니다. 따라서 성능 관점에서 볼 때 가능한 한 적은 수의 캐시를 사용하는 것이 좋습니다.