나는 동적 데이터가 전혀없는 여러 클라이언트 사이트를 유지합니다. 모든 것이 C# 인 정적 asp.net입니다.
일주일과 같이 극한 시간 동안 전체 페이지를 캐싱하는 데 어떤 실수가 있습니까?장기 정적 페이지 캐싱
키비 (Kibbee), 사이트의 몇 가지 컨트롤 (광고 로테이터, 일부 아약스 확장 기능)을 사용합니다. 그들은 아마 HTML로 완전하게 쓰여질 수 있었을 것이지만, 편의상 나는 다른 모든 사이트에 사용하는 것과 만 붙어 있습니다.
데이터가 없다고 말하면 asp.net 또는 C#을 어떻게 사용하고 있습니까? 일반 HTML에 비해 어떤 기능을 제공합니까? 또한 캐싱에 대한 계획을 세우는 경우에는 파일에 캐시 한 다음 요청이있을 때 파일을 스트리밍하는 것이 가장 좋습니다. OS는 항상 파일을 디스크에서 읽을 필요가 없도록 파일을 메모리에 보관합니다.
코드 업데이트가 필요한 경우 캐시를 지울 수 있는지 확인하기 위해 캐시 업데이트 메커니즘을 구축하고자 할 수 있습니다. 그 외에는 제가 생각할 수있는 문제가 없습니다.
데이터를 업데이트하려는 경우 캐시 시간이 오래 걸릴 수 있습니다. 안전을 위해 새 버전을 사용할 수있게되기까지 최대 1 주일이 소요될 것이라고 가정해야합니다. ISP 수준 프록시 서버와 같은 중간 호스트는 종종 공격적으로 캐시하므로이 지연이 발생합니다.
캐시 할 대용량 파일이있는 경우 콘텐츠 엔진이 If-Modified-Since를 지원하는지 확인해야합니다.
왕복 횟수를 줄이는 것이 중요하고, 만료 시간이 길며 (1 년?) 콘텐츠가 변경 될 때 URL을 변경하는 작은 파일 (페이지 콘텐츠, CSS, 이미지 등)의 경우 베스트. 이를 통해 사용자 에이전트가 새 콘텐츠를 가져올시기를 제어 할 수 있습니다.
야후! reducing HTTP requests 및 browser cache usage에 대한 두 편의 기사를 게시했습니다. 나는이 모든 것을 여기에서 반복하지는 않겠지 만, 이것들은 당신이 무엇을해야하는지에 관해 안내 할 좋은 책입니다.
내 감정은 대부분의 사용자 단일 세션을 처리 할 수있을만큼 충분히 높지만 콘텐츠를 업데이트하려는 경우 너무 많은 불편을주지 않을만큼 충분히 낮은 시간을 선택하는 것입니다. 모든 콘텐츠에 대해 Last-Modified가있는 경우 If-Modified-Since를 지원해야합니다.
마지막으로 콘텐츠를 캐시 할 수 있고 새로운 콘텐츠를 푸시해야하는 경우 항상 새 URL을 사용할 수 있습니다. 이 최종 캐시 가능 콘텐츠 URL은 최신 버전에 대한 영구 링크를 게시하려는 경우 고정 된 HTTP 302 redirect URL 뒤에 앉을 수 있습니다.
우리가 작업중인 프로젝트에서 비슷한 문제가 있습니다. 꽤 많은 데이터가 있습니다. 정적이지만 변경 가능합니다.
데이터를 로컬 파일에 저장 한 다음 변경 사항을 모니터링합니다. 파일을 제거하지 않으면 DB 서버가 손상되지 않습니다.이 경우 DB로 이동하여 데이터 파일을 재생성합니다.
그래서 우리는 기본적으로로드/저장, DB 서버에 대한 트래픽이없는 한 디스크 IO를 약간 가지고 있으며 우리는 여전히 그것을 제어합니다 (우리는 수동으로 삭제하거나 스크립트 등을 할 수 있습니다).
또한 디스크 IO를 줄이려면 실제 웹 서버 캐싱 모델로이 작업을 묶을 수 있습니다 (우리가 실제로 필요하지는 않음).
이 그것에 대해 갈 완전히 잘못된 방법이 될 수 있지만 우리 :)을 위해 아주 좋은 작동하는 것으로 보인다는
당신이 아마 한번 페이지를 생성하는 것이 더 후까지 봉사 할 것입니다 정적 인 경우 정적 HTML 파일을 직접 생성합니다.
정적 인 경우 캐싱이 전혀 필요없는 이유는 무엇입니까? IIS가 그것에 대해 걱정하게하십시오.