러시아 인형 캐싱 외에도 Rails 앱의 성능을 향상시키는 더 많은 기술이 있습니다. 이번에는 렌더링된 페이지를 사용자의 브라우저 캐시에 저장할 수 있게 해주는 Rails의 기본 제공 조건부 GET 지원에 대해 살펴보겠습니다.
👋 그리고 캐싱 이외의 성능에 대해 더 자세히 알고 싶다면 Ruby(on Rails) 성능에 관해 우리가 작성한 더 많은 내용이 있으며 Ruby 성능 모니터링 체크리스트를 확인하세요.
Etag 및 Last-Modified 헤더
브라우저가 Rails 앱의 페이지에 대해 HTTP GET 요청을 실행하면 라우터는 이를 컨트롤러 작업 중 하나에 연결합니다. 그런 다음 컨트롤러는 데이터베이스에서 필요한 데이터를 요청하고 뷰를 렌더링합니다. HTTP 응답(200 OK 포함) 응답 코드)는 브라우저가 구문 분석하고 표시할 수 있도록 응답 본문의 보기에서 렌더링된 HTML과 함께 브라우저로 다시 전송됩니다.
리소스가 다시 요청되면 동일한 파이프라인을 거치게 됩니다. 어떤 상황에서는 페이지가 그 동안 변경되지 않았기 때문에 이것이 필요하지 않습니다. 이를 위해 HTTP는 ETag를 제공합니다. 및 최종 수정 헤더. 이를 사용하면 브라우저는 응답 본문을 저장할 수 있으며 헤더가 오래되면 헤더를 사용하여 무효화할 수 있습니다.
E태그 또는 엔티티 태그 은 클라이언트 측 캐시 유효성 검사에 사용되므로 HTTP 응답의 캐시 키로 생각할 수 있습니다. 모든 요청에 대해 HTTP 응답 헤더를 통해 브라우저에 다시 전달됩니다.
~ $ 컬 -I http://localhost:3000/products/1HTTP/1.1 200 OK...ETag:W/"9462d76cc55aeb6249fa990e39231c7c"최종 수정:2018년 4월 25일 수요일 08:27:04 GMT...
나중에 응답이 반복되면 브라우저는 캐시에서 기존 응답을 찾아 마지막 요청에 저장된 Etag를 If-None-Match로 사용합니다. 헤더. 이 헤더는 Rails 앱에 이미 캐시에 이 버전이 있다는 것을 알려줍니다.
요청의 Etag가 현재 태그와 일치하면 Rails는 304 Not Modified를 보냅니다. 응답 본문이 없는 응답. 그러면 브라우저가 대신 로컬 캐시에 있는 캐시를 사용하도록 지시하게 됩니다.
~ $ 컬 -i -H 'If-None-Match:W/"9462d76cc55aeb6249fa990e39231c7c"' http://localhost:3000/products/1HTTP/1.1 304 수정되지 않음...ETag:W/"9462d76cc55aeb6249fa990e39231c7c"최종 수정:2018년 4월 25일 수요일 08:27:04 GMT...
Rails의 조건부 GET 요청
로컬 Rails 애플리케이션에서 페이지를 요청하면 Rails가 각 요청에 대해 자동으로 Etag를 추가하는 것을 볼 수 있습니다. 동일한 페이지를 연속으로 두 번 요청하면 각 요청에 대한 Etag 변경 사항을 볼 수 있습니다.
Rails는 기본적으로 각 요청에 대해 Etag를 생성하지만 이를 생성하기 위해 전체 응답 본문의 다이제스트를 사용합니다. 이는 <%= csrf_meta_tags %>를 의미합니다. 레이아웃에서는 각 요청에 대해 csrf-token 메타 태그가 변경되므로 Etag가 해제됩니다. 각 요청의 본문이 변경되므로 Etag는 무효화되고 로컬 캐시는 오래된 것으로 표시됩니다.
게다가 Rails는 결코 304 Not Modified를 반환하지 않습니다. 기본적으로 로컬 캐시는 컨트롤러에서 명시적으로 새로운 것으로 표시되지 않기 때문입니다.
fresh_when 그리고 stale?
조건부 GET에 대한 요청 헤더에서 Etag를 사용하려면 로컬 캐시의 객체를 "새"로 명시적으로 표시해야 합니다. 예를 들어 제품을 표시하는 페이지의 경우 제품과 뷰 템플릿이 변경되지 않는 한 캐시를 최신 상태로 유지할 수 있습니다. 이를 실현하기 위해 우리는 두 가지 일을 할 것입니다.
- 전체 응답 본문을 사용하려면 캐시된 응답이 유효한지 확인하기 위해 전체 본문을 렌더링해야 하므로 Etag를 구성할 값을 명시적으로 설정합니다. 그러면 페이지를 로컬로 캐시하는 데 따른 속도 향상이 무효화됩니다.
- 요청 헤더의 Etag를 이전에 예측한 Etag와 비교할 것입니다. 뷰를 렌더링하고 일치하는 경우 렌더링을 생략합니다.
Rails에는 우리를 위해 모든 작업을 수행하는 도우미가 함께 제공됩니다. fresh_when를 사용하여 제품의 Etag 및 최종 수정 날짜를 명시적으로 기반으로 할 수 있습니다. .
명시적인 respond_to이 있는 경우 차단하려면 stale?을 사용하세요. fresh_when 대신 .
이제 제품 페이지 중 하나를 요청하면 응답이 로컬로 캐시됩니다. 동일한 페이지에 대한 모든 후속 요청에는 캐시된 응답이 있음을 Rails에 알리는 Etag가 포함되며, 그런 다음 새 Etag와 비교됩니다. 일치하면 Rails는 페이지 렌더링을 건너뛰고 304 Not Modified를 반환합니다. 즉시.
참고 :페이지를 새로 고치면 항상 캐시되지 않은 페이지 버전이 요청됩니다. 조건부 GET이 작동하는지 테스트하려면 대신 링크를 사용하거나 뒤로 버튼을 사용하여 다른 곳으로 이동하세요.
이 기사와 AppSignal Academy 시리즈의 이전 기사가 마음에 드셨나요? Rails의 캐싱에 대한 기사가 더 많이 준비되어 있습니다. 다음 번에 작성하고 싶은 내용(캐싱 관련 또는 기타)에 대해 주저하지 말고 알려 주시기 바랍니다!
