레일 조각 캐싱 : 100K + 조각이 성능을 저하시킬까요?

Question

나는 많은 양의 데이터로 사이트를 가지고 있고 이런 모든 페이지에 "러시아 인형"캐싱을하고 있어요 :

# articles.html.haml 
- cache "list of articles", expires_in: 15.minutes do 
    = render partial: "article", collection: @articles 

# _article.html.haml 
- cache article do 
    = article.body 
    = render partial: "comment", collection: article.comments 

# _comment.html.haml 
- cache comment do 
    = comment.body 

이 수천 조각의의 수백을 만들 것입니다.

1./tmp/cache 디렉토리의 많은 조각 파일로 인해 성능이 저하됩니까?

2. 레일이 자동으로 만료되면 오래된 조각을 자동으로 삭제합니까?

추신. 이 사이트는 4GB RAM이있는 단일 우분투 서버에 있습니다. 캐시 저장소로 memcached를 사용하지 않고 표준 파일 기반 구현으로 레일 박스를 즉시 사용할 수 있습니다.

Answer 1

어느 시점에서 캐시 히트가 조각을 생성하는 것보다 비용이 덜 듭니까 질문해야합니다. 대답이 예 (벤치마킹 가능) 인 경우 캐시되지 않은 상황에 비해 성능이 향상됩니다. 물리적 (플래터) 하드 드라이브에 저장된 수십만 개의 캐시 조각의 경우 I/O 병목 현상에 매우주의해야합니다. 이것이 문제가되는 경우 파일 수를 줄이기 위해 캐싱 전략의 깊이를 제한 할 수 있습니다. 그러나 다시 한번 벤치마킹하십시오. 높은 히트 율 (high hit rate)은이 특정한 경우에 I/O를 제한 할 것이기 때문에 히트 율은 매우 중요한 통계입니다.

성능에 문제가있는 경우 조각이 만료되는 빈도를 살펴보십시오. 귀하의 특정 상황에서, "기사 목록"은 코멘트가 게시 될 때마다 무효가됩니다. 현재 15 분마다 만료되지만 출력 결과를 일관되게 유지하려면 코멘트 또는 기사를 배치하거나 편집 한 직후에 실제로 만료되어야합니다. 기사 목록에 분당 여러 개의 댓글이있는 경우 개별 댓글을 여기에 캐시해도됩니다. I/O가 문제가되면, 항상 RAM을 추가하고 memcached (또는 redis)를 사용하여 시작할 수 있습니다.

그러나 캐싱의 여러 레이어가 있기 때문에 파일 시스템에 대한 몇 가지 히트와 함께 상위 "기사 목록"조각에 대한 조회수만으로도 충분합니다.

Answer 2

Windows 서버에서 호스팅하지 않는 한 Rail의 캐시에있는 여러 폴더에 퍼져있는 100K 파일은 성능에 영향을 미치지 않습니다.