Varnish가 Magento 사이트를 캐시하는 데 필요한 수정 사항에 대한 좋은 예제를 찾기 위해 고심하고 있습니다.

이상적으로는 비활성화 / 활성화 할 항목 및 찾을 위치와 같은 작업 목록을 원합니다. 이러한 변경 사항이 적용되도록 Varnish 구성을 사용하는 것이 좋습니다.

Magento 성능 안내서는 Varnish에 대해 많이 이야기하므로 이전에 완료되었지만 실제로 작동하는 방법을 설명하지는 않습니다.

여기에는 공식 모듈이 있습니다 . 필요한 모든 것을 포함합니다 (varnish config, module, ...)

니스가 당신에게 맞습니까?

바니시는 마 젠토 성능의 전부가 아닙니다. 봇 및 창 구매자의로드를 상쇄하는 것이 좋지만 실제로 매장을 더 빨리 만드는 첫 번째 포트가되어서는 안됩니다.

실제로, Varnish 구현은 상점 의 마지막 성능 수정 이어야합니다 . 마 젠토가 페이지없이 로딩 할 수있는 시간 (예 : <600ms 페이지 로딩 시간)을보고 난 후에 만 ​​드롭하십시오.

상점은 여전히 ​​빨라야합니다

Varnish는 여전히 캐시를 프라이밍하기 위해 최소한 하나의 페이지로드를 필요로하므로 캐시되지 않은 성능이 여전히 우수해야합니다. 다음과 같은 경우를 제외하고는 대부분의 고유 URL (계층 탐색 적중, 검색어 등)이 니스에서 제공되지 않습니다.

a) 귀하의 TTL이 너무 높아서 4 일 전의 검색어가 여전히 유효합니다.
b) 사이트의 발자국이 너무 커서 URL이 매우 짧은 시간 내에 채워집니다.

또한 모든 매장이 Varnish에 적합하지는 않다는 점도 고려해야합니다 . 고객 여정 초기에 사용자가 개인 세션 (예 : 로그인, 장바구니에 추가 등)을 만들도록 권장하는 모든 사이트는 Varnish가 궁극적으로 중복됨을 의미합니다.

예를 들어, 개인 쇼핑 사이트는 처음부터 사용자 로그인을 권장하지만, 이렇게하면 Varnish는 캐시 할 수없는 고유하지 않은 콘텐츠를 실제로 가질 수 없습니다. 따라서 적중률이 크게 낮아지고 니스를 사용하면 아무런 이점이 없습니다.

최신 콘텐츠 또는 더 높은 적중률

^{이미지 제공 : magestack.com}

효과적인 니스 사용은 오래된 콘텐츠와 사이트 방문자 수 간의 균형을 유지하는 것입니다.

바쁜 사이트를 가지고 있다면 낮은 TTL로 도망 칠 수 있지만 여전히 높은 바니시 적중률을 유지할 수 있으며 낮은 TTL을 유지할 수 있으므로 더 신선한 콘텐츠를 얻을 수 있습니다. 따라서 귀하의 재고 / 가격 변동이 신속하게 반영되고 지속적으로 발생하는 용량에서 캐시가 시작됩니다.

트래픽이 적은 사이트가 있다면 타협해야합니다. 더 높은 적중률을 보장하거나 최신 컨텐츠를 갖도록 TTL을 늘리십시오. 둘 다 가질 수는 없습니다. 예, 크롤링 / 스파이더 도구를 계속 실행할 수는 있지만이 도구는 소비하는 리소스와 크롤링 할 수있는 볼륨 또는 URL (일반적으로 소규모 상점 의 경우 수만 개)이 단순히 효과적이지 않음을 의미합니다. 따라서 일반적으로 소규모 상점은 FPC 확장 이 우수 하고 최적화 된 서버 구성을 통해 더 많은 이점을 얻을 수 있습니다.

그러나 물론 사용자가 로그인 한 경우에도 니스를 사용할 수 있습니다. 사용자 별 캐시 또는 ESI는 어떻습니까?

ESI

ESI는 캐시에 컨텐츠를 보관할 수 있고 여전히 페이지에 동적 블록을 가질 수있는 훌륭한 유틸리티입니다. 그러나 효과적으로 사용하려면 콜백 양을 최소한으로 최소화해야합니다. 이 프로세스의 기초로 사용할 수 있는 작은 헤드 스타트 모듈 이 있습니다 . 보안 구멍을 단단히 고정하고 기본적으로 매우 안전하지 않은지 확인하십시오.로드 할 수없는 /로드 할 수없는 레이아웃 처리에 대한 제한은 없습니다

Magento 부트 스트랩이로드 될 때마다 약 200ms의 성능 저하가 발생합니다. 블록을 수집 / 렌더링하기 전에도 마찬가지입니다. 따라서 ESI가 3 배 이상인 경우에는 동적 콘텐츠에 대해 Varnish + ESI를 사용하면 페이지를 로딩하는 시간이 단축됩니다. Varnish를 무시하고 요청을 Magento 자체에 직접 전달하는 것보다 낫습니다.

따라서 실제로 ESI를 효과적으로 사용하려면 여러 요청을 단일 요청으로 결합 할 수 있어야합니다.

예를 들어, 20 개의 제품을 나열하는 카테고리보기 페이지에는 정확한 재고 레벨이 표시되어야합니다. 따라서 페이지의 각 블록에 대해 ESI를 사용합니다. 이는 ESI 주식 요청의 20 배입니다. 재고 요청은 매우 가볍지 만 동시에 20 배를 실행하면 성능이 저하됩니다. 대신, 20 개 제품의 전체 블록 / 컬렉션을 제공하고 1x 요청을받을 수 있습니다. 그러나 컬렉션을로드하고 렌더링하는 것은 아마도 페이지에서 가장 느린 요소 일 것이므로 많이 얻지 못했습니다.

ESI를 효과적으로 사용하려면 적절한 계획과 실행이 필요합니다. 또는 니스를 전혀 사용하지 않는 것보다 사이트 속도가 느립니다.

사용자 당 캐시

그런 다음 사용자 별 캐시를 사용하는 대안이 있습니다. 트래픽이 매우 적은 사이트가 없으면 좋지 않습니다. 방문자가 이미 방문했던 페이지와 같은 페이지를 방문 할 확률은 매우 낮기 때문에 귀하의 방문률은 매우 낮습니다. 그리고 각 고객에 대해 해당 6Kb 페이지는 니스 저장소의 더 많은 공간을 차지합니다.

예를 들어, 니스에 1GB를 할당 한 경우. 사용자가 방문당 8 페이지를 보는 일반적인 사이트에서는 평균 6 페이지가 고유합니다. 스토리지 1MB 당 방문자 수는 28 명입니다. 그런 다음 이미지, CSS 및 JS를 고려하십시오-이것들은 (고맙게도) 일반적이지만 여전히 7-800MB의 사용 가능한 저장 공간을 차지할 것입니다. 이로 인해 200MB의 스토리지가 남아 있으며 5,600 명의 고유 방문자를위한 충분한 캐시가 남습니다.

글쎄, 난 상관 없어, 난 그냥 바니시를 원해

좋아, 그러면 다음을 수행해야합니다.

1. 바니시 앞에 앉아 SSL 터미네이터를 설치하십시오 (예 : 스터드 / 파운드 / nginx)
2. 서버에 바니시 설치
3. X-Forwarded-For올바르게 구성 했는지 확인하십시오
4. 바니시 모듈 설치상점에
5. 타사 확장 프로그램을 제외하도록 Varnish VCL 설정

처음 3 점은이 답변의 범위를 벗어나므로 직접 처리하도록하겠습니다. 포인트 4는 어린이의 놀이이며 포인트 5 는 계속 읽습니다.

니스 구현에서 가장 중요한 것은 절대로 캐시해서는 안 캐시 컨텐츠를.

예 :

• 결제 게이트웨이 콜백
• 카트 개요
• 고객 내 계정 개요
• 체크 아웃 (및 해당 Ajax 호출)

기타

핵심 Magento URL의 경우 Varnish에서 이스케이프 할 수있는 상당히 표준적인 URI 목록이 있습니다.

admin|checkout|customer|catalog/product_compare|wishlist|paypal

그러나 사용자 지정 경로, 라우터 및 네임 스페이스가있는 실행중인 사용자 지정 / 3 자 확장도 고려해야합니다. 불행히도 이러한 확장의 URL을 캐시 할 수있는 것과 캐시 할 수없는 것을 쉽게 알 수있는 방법은 없습니다. 따라서 각 사례별로 평가해야합니다.

일반적으로 Varnish를 구성 할 때마다 해당 경로, 라우터 및 네임 스페이스를 식별하여 시작합니다. SSH를 통해이 작업을 수행합니다.

grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community 
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local 

이것은 당신에게 결정적인 URL 목록을 제공하지는 않지만 거의 확실하게 시작점을 줄 것입니다.

캐시되지 않아야하는 콘텐츠를 캐시하지 않는 것이 얼마나 중요한지 강조 할 수 없습니다. 결과는 치명적일 수 있습니다.

요약해서 말하자면

다른 Magento 서버 성능 최적화와 마찬가지로 올바르게 구현 및 조정하면 실제로 이점을 얻을 수 있습니다. 그러나 소프트웨어를 올바르게 구성하지 않고 단순히 소프트웨어를 삭제하면 매장이 더 빨라질뿐만 아니라 잠재적으로 느리고 안전하지 않으며 신뢰성이 떨어집니다.