공유 프록시 캐시가 크롤러에 도움이 될 때
공유 포워드 프록시 캐시가 처리량을 높여 줄 것이라 기대하기 전에 반복되는 리소스, 최신성, 크롤러의 실제 요청을 평가하세요.
브라우저에서 여러 워커가 같은 사이트의 서로 다른 페이지를 연다고 가정해 봅시다. 그 페이지들은 동일한 스타일시트, 로고, 스크립트 번들을 참조합니다. 공유 포워드 캐시는 응답을 재사용할 수 있을 때 첫 요청을 이후 워커에게도 유용하게 만들 수 있습니다.
이제 작업 부하를 바꿔 보세요. 각 워커는 HTML 문서 하나만 내려받고 연결된 리소스는 전혀 로드하지 않습니다. 공통 스타일시트는 마크업에 그대로 있지만 어떤 워커도 요청하지 않습니다. 그것은 프록시의 캐시 적중률에 아무것도 기여하지 않습니다.
크롤러가 실제로 보내는 요청부터 시작하세요
페이지를 렌더링하는 브라우저와 그 소스를 가져오는 HTTP 클라이언트는 서로 다른 요청 집합을 만듭니다. 캐시 설계를 고르기 전에 그 집합을 살펴보세요.
| 작업 부하 | 공유 재사용 가능성 |
|---|---|
| 워커가 같은 공개 자산을 반복해서 가져온다 | 최신성과 캐시 키 규칙이 허용할 때 유용함 |
| 모든 요청이 고유한 URL이나 응답 변형을 가진다 | 재사용할 중복이 거의 없음 |
| 재사용 전에 응답 재검증이 필요하다 | 응답 바이트는 아낄 수 있지만 업스트림 왕복은 여전히 필요함 |
| 워커가 자체 로컬 캐시에서 요청을 이미 처리한다 | 그 요청은 공유 프록시에 도달하지 않을 수 있음 |
URL이 같다는 것만으로는 충분하지 않습니다. 응답의 최신성 정책과 Vary가 지정한 필드가 표현을 구분할 수 있습니다. 비공개이거나 저장할 수 없거나 인증된 콘텐츠에는 해당 공유 캐시 규칙이 필요합니다. 적중 횟수를 올리기 위해 하나의 공개 결과로 강제해서는 안 됩니다.
일반적인 HTTPS CONNECT 트래픽에서 포워드 프록시는 암호화된 터널을 전달하며 그 안에 캐시할 HTTP 객체가 없습니다. TLS 검사 배포는 신뢰와 처리 방식이 다릅니다. 객체 캐시가 가능한지 평가할 때 실제 모드를 포함하세요.
캐시 적중은 업스트림 가져오기를 피할 수 있지만, 미스는 여전히 중간자의 작업 비용을 치릅니다. 의도한 작업 부하에 대해 완료된 유용한 바이트, 업스트림 트래픽, 지연 시간을 비교하세요. 스레드 수는 동시성을 설명할 뿐, 그 스레드들이 얼마나 많은 재사용 가능한 콘텐츠를 공유하는지는 설명하지 않습니다.