나는 Rails 백엔드에 대한 적중을 저장하기 위해 Varnish 역방향 프록시 캐시를 사용하는 Ruby on Rails에서 실행되는 대부분 정적 사이트를 가지고 있습니다.
문제는 사용자가 사이트에 로그인할 수 있고 로그인할 때 ESI(Edge Side Includes)를 사용하여 사용자에게 페이지의 특정 부분을 표시한다는 것입니다.
ESI를 사용한다는 것은 Rails 백엔드에서 Gzip 압축을 비활성화해야 함을 의미합니다(Nginx+passenger 사용). 그렇지 않으면 varnish가 ESI 처리를 실행하기 위해 백엔드에서 반환된 데이터를 구문 분석할 수 없습니다.
내 질문은 역방향 프록시 캐시를 사용하는 이점이 모든 콘텐츠를 gzip으로 압축하는 이점보다 중요하다는 것입니다. 아니면 ESI를 완전히 제거하고 두 가지 장점을 최대한 활용해야 합니까?
답변1
다음과 같이 정리하면 두 가지 장점을 모두 얻을 수 있습니다.
사용자 -> nginx -> 바니시 -> 레일
nginx에서 사용자에게 gzip 압축을 켜십시오. 이는 가장 느린 부분이자 가장 비용이 많이 드는 부분입니다. 나는 귀하의 nginx, Varnish 및 Rails 인스턴스가 서로 로컬이라고 가정합니다. 로컬 대역폭이 충분해야 합니다. 게다가 ESI를 조립하기 위해 압축을 풀기 위해 gzip을 사용하는 것은 그다지 의미가 없습니다.
답변2
대역폭이 문제가 되지 않고 로드 시간이 gzip 없이도 허용된다면 gzip을 꺼두어야 합니다.
Gzipping은 많은 CPU 리소스를 사용합니다. 따라서 대역폭보다 CPU에 더 관심이 있고 사이트가 충분히 빠르게 로드되고 ESI가 큰 도움이 된다면 역방향 프록시 캐시 시스템은 http 응답을 gzip하는 것보다 확실히 더 많은 이점이 있습니다.
대역폭이 중요한 다른 상황에서는 gzip이 더 중요할 수 있지만 여기서는 그렇지 않은 것 같습니다.
마지막으로 일부 역방향 프록시를 사용하여 gzipping을 수행할 수 있습니다. 역방향 프록시는 일반적으로 CPU를 많이 사용하지 않기 때문에(별도의 서버에 있는 경우) 이는 매우 가능성이 높습니다. 이렇게 하면 백엔드의 CPU 주기가 많이 절약되고 대역폭도 절약됩니다. 하지만 현재로서는 제가 정확하게 기억한다면 Varnish는 gzipping을 지원하지 않습니다.