CE 1.8의 전체 페이지 캐시-FPC 마 젠토 모듈? 광택? 양자 모두?


15

Community Edition 1.8의 Full Page Caching을 연구 할 때 약간 혼란스러워합니다. 이미 CDN 2 레벨 Redis 캐시를 구현하여 최대 성능 (DB는 물론 별도의 서버에 있음)에 맞게 MySQL의 my.cnf를 조정했으며로드 밸런서 뒤에 스토어를 호스팅하는 2 대의 서버가 있습니다. 초기 성능 조정을 수행하기 전에 FPC를 즉시 뛰어 넘지 않는다고 지적합니다.

Magento는 물론 모든 종류의 사이트에서 Varnish를 사용한 적이 없으며 Magento에서도 FPC를 설정 한 적이 없습니다. Varnish는 CDN과 CD의 페이지 캐시 사이의 교차 역할을하는 프록시로, 웹 서버에 요청을 보내기 전에 브라우저로 데이터를 보내는 프록시라는 것을 알고 있습니다. 그리고 이해하기 위해, FPC 모듈은 웹 서버 자체가 떨리는 캐시를 로컬로 만듭니다. 두 가지 설정 모두 동적 콘텐츠를 브라우저로 가져 오려면 "홀 펀칭"을 수행해야합니다 (모듈을 사용하거나 광택을 사용하는 방법은 기술이 다르지만). 여기에 오해가 있으면 수정 해주세요.

지금까지는 사이트를 구현하는 데 도움이되는 두 개의 개별 엔티티로 생각했지만 지금 읽은 내용은 그 반대입니다. 저의 원래 계획은 마 젠토 (이전의 "Tiny Brick Lightspeed FPC")를위한 " 워프 고급 풀 페이지 캐시 "모듈 을 구입하는 것이 었습니다. , 350 달러는 우리 회사, 특히 그것이 할 수있는 일에별로 중요하지 않습니다. 저 자신과 동료 개발자 2 명은 자신 만의 맞춤 제작 수제 테마 내에서 적절하고 완벽하게 구현하여 학습 할 수있는 것을 극대화하는 방법을 배우려고 계획했습니다. 그 후, 어느 시점에서 나는 바니시를 구현하는 것을 고려할 것이라고 생각했지만, 앞에서 말했듯이 나는 그것들이 분리 된 것으로 이해했습니다.

그러나 이제는 무료로 제공되는 PageCache Powered by Varnish 또는 거의 $ 800 USD 인 Varnish Cache로 구동되는 Vortex Cache와 같은 확장 프로그램을 사용하기 시작했습니다.

스택 교환, 당신에게 내 질문은 어떻게 FPC와 광택을 볼 수 있습니까? 별도의 엔티티로? 그렇다면 상호 배타적입니까? 그들은 함께 구현해야하는 동일한 동전의 양면입니까? 아니면 그것들이 비슷하지만 서로 배타적이지 않고 포용 적이 지 않습니까?

위에서 언급 한 Warp Advanced FPC를 Varnish와 함께 사용할 수 있습니까? 니스와 함께 사용해야합니까 ? 또는 니스를 사용할 계획이라면 다른 FPC를 사용하는 것이 더 좋습니까? 아니면 F 니스가 없어서 니스가 필요하지 않습니까? 또는 그 반대로 Varnish를 사용하고 FPC 아이디어를 버려야합니까?

글의 벽은 미안하지만 많은 기사, 블로그 및 포럼 게시물을 살펴 보았는데 그 질문에 대한 명확한 대답을 알 수 없었습니다. 이 문제에 대한 귀하의 도움과 의견에 진심으로 감사드립니다 =)

마지막으로 니스와 웹 서버에 대한 간단한 질문입니다. 현재 일반적인 Apache LAMP 스택 설정을 사용하고 있지만 한동안 사람들이 Magento와 함께 Nginx를 사용하는 것에 대해 열광하는 것을 보았습니다. 나는 몇 가지 테스트, 스트레스 및 부하 테스트를 수행했으며 올바른 조건에서 확실히 더 잘 작동하는 것 같습니다. 따라서 가까운 시일 내에 전환을 고려하고있었습니다. 어쨌든 이것이 FPC 및 / 또는 바니시 사용에 대한 나의 소망과 결정에 영향을 미칩니 까?

감사합니다!!!

편집 : 아! 그리고 하나 더 빠른 질문-로드 밸런서 뒤에 내 사이트를 호스팅하는 두 대의 서버 (필요한 경우 수평으로 증가 할 수있는 설정)가 있기 때문에 별도의 서버에서 호스팅되는 Redis와 Memcached를 최대한 활용합니다. 내 세션과 Magento의 각 레벨 (잘, Zend)의 2 레벨 캐시에 대한 웹 및 DB. FPC가 시스템의 데이터 중 하나에 데이터를 저장한다고 가정합니까? 거기에 저장하거나 모두 확장하려면 특정 확장이 필요합니까? 그리고 내가 아닌 것으로 가정하지만, 이것은 어쨌든 바니시에 영향을 미칩니 까? 다시 감사합니다 !!


분명히 나는 ​​평판이 부족하여 텍스트 벽에 두 개의 링크 만 넣을 수 있습니다. 인터넷 포인트를 트롤하도록 권유하는 방법 ... 링크는 다음과 같습니다. Varnish Cache로 제공되는 Vortex Cache aaand PageCache Varnish로 제공
ThatSourDiesel

3
나는 니스에 대해 많은 조언을 제공 할 수 없다,하지만 난 Lesti FPC 한 번 봐 가지고 추천 - gordonlesti.com/lestifpc는 그것은 완전히 무료 홀 펀치를 가지고, 관리자를 통해 구성 할 수 있습니다. 절대적으로 훌륭합니다.
Paul

@ThatSourDiesel-당신이 한 일을 말해 줄 수 있습니까? 적어도 솔루션에 대해 사용한 경우 허용되는 답변 아래에있는 것이 좋습니다.
SPRBRN

답변:


28

컴퓨터 과학에는 두 가지 어려운 점이 있습니다.

  1. 명명 것들
  2. 캐시 무효화.

홀 펀칭은 카테고리 # 2에 속합니다. :)

일반

가장 좋은 방법은 스택의 하단에서 시작하여 Magento의 프런트 엔드까지 최적화하는 것입니다.


데이터베이스 및 파일 시스템

항상 첫 번째로 집중해야하는 영역이어야합니다. 때문에. I / O

MyTop 은 Linux 'top'명령을 모방하여 MySQL 인스턴스 상태에 대한 통찰력을 제공하는 편리한 Linux 기반 펄 스크립트입니다.

Htop보다 강력한 상단입니다 . strace 기능은 잠재적 병목 현상을 찾기 위해 프로세스의 입 / 출력을 결정하는 데 도움이됩니다.

Iotop 은 I / O 모니터링을 위해 고려해야 할 또 다른 도구입니다.

mysqltuner.plmysql tunning primer 와 같은 기타 편리한 유틸리티 스크립트는 MySQL 런타임 변수에 대한 통찰력을 제공하고 조언을 제공 할 수 있습니다. 최선의 접근 방식은 수집 된 알려진 데이터를 기반으로 요구 사항 및 조정을 항상 평가하기 때문에 이는 가이드를위한 것입니다. 맹목적으로 그렇게하면 때때로 좋은 것보다 더 많은 피해를 줄 수 있습니다. 그리고 적어도 24 시간의 mysql 런타임 변수없이 조기에 실행하면 나쁜 조언을 제공 할 수 있습니다.

명심 Percona 위의 모든 작업을해야한다, MariaDB 및 표준 MySQL을. Magento는 InnoDB에서 너무 무겁고 XtraDB는 db 엔진에 많은 도구와 향상된 기능을 제공하기 때문에 Percona를 MySQL 포크로 선호합니다.


아파치 또는 Nginx

아파치를 사용하면서 다른 많은 사람들에게 잘 제공되었으므로 여전히 아파치를 사용합니다. Nginx도 사용하고 구성했습니다. 몇 가지 장점을 제공하지만 학습 곡선이 있습니다. 이 두 가지가 모두 널리 사용되는 옵션이지만 Apache보다 몇 가지 장점이 있지만 하나는 더 작은 메모리 공간입니다. 그러나 PHP-FPM을 실행하는 축소 된 Apache는 유사한 메모리 공간을 갖습니다.

지목 사항:

이 기사는 성능에 관한 것이기 때문에 아파치가 독자적인 방식으로 벗어날 수있는 가장 쉬운 방법 중 하나는 .htaccess 파일을 사용하지 않는 것입니다. 디렉토리 스탠자에 넣은 것을 넣고 AllowOverride를 "None"으로 설정하면 아파치가 .htaccess에주의를 기울여야하는지 여부를 파악하기 위해 전체 문서 경로를 순회하도록 요구하지 않습니다. 이것은 많은 사람들이 그리워하는 기본적이고 간단한 튜닝 힌트입니다.

이 체크 아웃을 용이하게하려면 :

CDN을 사용하면 어느 쪽이든 쉽게 사용할 수 있지만 대부분의 최종 사용자 브라우저는 동일한 수의 연결 제한으로 두 서버에 연결할 수 있으므로 프런트 엔드 최적화에 이점이 있습니다. 또한 Apache가 검사를 거치지 않고 단순한 정적 이미지를 제공 할 필요가 없습니다. Lighthttpd 는 CDN 이외의 컨텐츠에 대해서만 정적 웹 서버를 실행하려는 경우 옵션입니다.

PHP

PHP-FPM 및 APC. Magento에 필요하지 않거나 필요하지 않은 PHP 모듈을 제거하고 사용하십시오.


마 젠토 코드베이스

AOE_TemplateHints 는 블록이 올바르게 캐싱되는지 확인하는 데 좋습니다.

AOE_Profiler 는 프로파일 링에 적합하며 반드시 DB 레이어 프로파일 링을 활성화하십시오 (로컬 / dev 환경에서). 앞에서 언급 한 mytop 도구 와 함께 사용하면 잘못된 동작 SQL을 찾는 것이 더 쉬워집니다.

타사 모듈 및 사용자 정의 코드

Magento 자체의 최적화를위한 가장 좋은 모범 사례는 잘 읽었으며 타사 모듈을 사용하기 전에 검토 할 때 명심해야합니다. (나쁜 행동을하는 사람들이 많이 있습니다. IMO).

Magento ECG의 Magniffer 도구를 사용하면 위에 제공된 PDF를 기반으로 잘못된 동작 코드를 쉽게 식별 할 수 있습니다. 그러나 symfony / php-parser 기반이지만 composer를 통해 설치할 수 있습니다.


광택

하나는 단순히 광택을 켜지 않습니다

바니쉬를 옹호하는 작가는 FreeBSD 커널 개발자였으며, 초 미만의로드 시간을 제공합니다. 그러나 기본적으로 제공되지 않는 템플릿에 약간의 차이가있는 경우에도 필요한 내용을 펀치 펀치하도록 varnish / magento를 구성하는 데 시간이 걸립니다. 내가 본 대부분은 단순히 니스에서 캐시되지 않은 필요한 항목을 AJAX'ify합니다.

이 홀 펀칭 및 캐싱을 용이하게하는 여러 가지 Magento 모듈이 있습니다.

궁극적으로이 최적화 여행의 마지막 말에해야하고, 수도 가지 권리를 얻기 위해 몇 가지 사용자 정의가 필요합니다.


마 젠토 CE FPC

지금까지 내가 찾은 최고의 CE FPC는 다음과 같습니다. Lesti :: FPC

커뮤니티를 위해 매우 잘 짜여진 (모든 관찰자 기반) 오픈 소스 및 무료 FPC입니다.


하루가 끝나면 자신의 테스트와 판단을 사용하십시오.

더 읽을 거리 :


2

이 스레드에 대해 조금 늦었지만 여전히 솔루션을 찾고 있다면 Evolved Caching 을 고려할 수 있습니다 . 워프와 동일한 가격이지만 다음과 같습니다.

  • 설치 및 구성이 매우 쉽고 빠릅니다. 모든 홀 펀칭 및 구성은 관리자 내에서 수행됩니다.
  • Varnish와 직접 통합되며 Magento 내에서 Varnish 캐시를 지우고 예열 할 수 있습니다
  • 1.8 CE에 도입 된 프론트 엔드 form_key와 Varnish 및 자체 캐시에서 작동합니다.
  • 반응 형 지원으로 매우 적극적으로 개발되었습니다. 보고 후 며칠 내에 버그 수정을 릴리스 할 목적으로 정기적 인 새 버전
  • 모든 릴리스마다 업데이트되는 광범위한 설명서 가 있습니다.

Varnish로 설정하는 것은 간단합니다. 관리자 설정 만 활성화하고 여기에 있는 .vcl을 사용하면 됩니다 . 또한 쿠키는 평소와 같이 존재하지 않을 때 캐시 만 제공하는 캐시에만 제한되지 않습니다. 캐시 적중률이 매우 높습니다.


오, 재밌 네요. 나는 확실히 그것을 살펴볼 것입니다. 여기에 업데이트를 게시해야합니다. 기본적으로 전체 페이지 캐시 모듈이 아닌 Varnish를 사용하기로 결정했지만 동적 부분에 대해 어떻게해야하는지 조금 고민했습니다. 대부분 ESI와 AJAX. 나는 Turpentine / Varnish를 사용해 보았지만 장바구니에 물건을 추가하는 데 문제가 있었을 때 나는 그것을 뽑았습니다. 문제가 memcached 세션 저장 핸들러와 관련이 있음을 알았습니다. 나중에 찾았습니다. 따라서, 나는 여전히 바니시를 백업하고 싶지만 모든 동적 부분이 제대로 작동하는지 확인하는 데 시간을 소비해야합니다.
ThatSourDiesel

1
그래 프론트 엔드에 form_key가 포함되어 있기 때문에 Turpentine이 1.8 CE와 함께 작동한다고 생각하지 않습니다. 이것이 장바구니에 추가하는 데 문제가있는 이유 일 수 있습니다. 개인적으로 나는 ESI가 페이지를 전달하기 전에 Magento에 요청을 보내야하므로 항상 ASIx를 ESI보다 추천하고 싶습니다. 이것은 항상 느릴 것입니다. 이 게시물을보고 싶을 것입니다. fabrizio-branca.de/magento-varnish-ajax-vs-esi.html .
Jonathan Hussey

나는 Fabrizio의 블로그를 좋아합니다! 그의 AJAX 모듈을 확실히 보았습니다. 그것이 저의 마지막 주석에서 AJAX를 언급했을 때 언급 한 것입니다. 장바구니에 추가 문제는 실제로 해결할 수있는 memcached의 이상한 문제로 인한 것입니다. 즉, form_key를 비활성화하지 않으면 Turpentine이 1.8에서 작동하지 않는다고 말하더라도 나에게 잘 작동하는 것 같습니다. 그러나 그 시점에서 ESI를 완전히 이해하지 못했기 때문에 구현 및 테스트에 더 많은 시간을 할애 할 수있을 때까지 ESI가 비활성화되었습니다. 나는 최근에 약간의 일을 놓쳤다. 쇄골이 부러졌고 수술을 받아야했다.
ThatSourDiesel

BTW, Evolved Caching은 자신의 모듈입니까? 호기심에서-스테이징 서버에서 샷을 주실 수 있습니까? 우리는 PM 도메인 이름과 그렇지 않은 것에 대해 토론 할 수 있으므로 실제로 테스트 서버인지 프로덕션이 아닌지 확인할 수 있습니다. =)
ThatSourDiesel

수술 후 회복되기를 바랍니다. 예, 모듈은 내 회사에서 개발 한 것입니다. 예, 준비 / 개발 도메인에서 모듈을 시험 사용하게되어 매우 기쁩니다. 스토어 왼쪽 열에 고객 서비스 이메일 주소를 사용하여 이메일을 보내 주시면 store.husseycoding.co.uk를 선택 하겠습니다 . 부수적으로, memcached 문제를 해결하게되어 기쁩니다. 폼 키가 캐시 될 때 페이지를 캐시하는 사용자에게는 장바구니에 추가가 1.8 미만에서 작동하는 것처럼 보일 수 있지만 쿠키를 지우면 새 쿠키를 얻을 수 있습니다 세션 + 양식 키를 누르면 아마도 실패했을 것입니다.
Jonathan Hussey

1

우리는 Magento 1.8 새로운 폼 키와 호환되는 FPC를 작성했습니다. 림의 전체 페이지 캐시 : http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER는 스택에서 시작하여 작업을 시작하는 데 큰 도움이됩니다. FPC 또는 바니시는 마지막에 있어야합니다. 성능 감사를 수행하고 MySQL 및 APC 구성과 관련하여 문제가있는 경우가 많습니다. Innodb 버퍼 크기가 기본값으로 설정되고 데이터베이스가 그 이상으로 성장했습니다.

함께 작동하도록 특별히 설계된 경우가 아니라면 Fnish와 함께 FPC를 사용하지 않는 것이 좋습니다. 일반적으로 코드베이스와 함께 조정되고 트래픽을 유지하기 위해 고심하고있는 소수의 강력한 서버가 없다면 바니시는 권장하지 않습니다. 요청을 Magento 백엔드로 제한하고 부하를 줄이려고 할 때 Varnish를 사용하면 동적 콘텐츠를 업데이트하는 것이 까다로울 수 있습니다. 하나 또는 두 개의 웹 헤드가있는 경우 시간과 합병증의 가치가 없을 수 있습니다.

대부분의 상황에서 서버와 코드베이스를 조정 한 후에는 좋은 FPC로 필요한 성능을 얻을 수 있습니다. FPC를 사용하면 레벨 1 캐시에서 15ms 미만의 생성 시간을, 표준 캐시에서 100ms 미만의 생성 시간을 얻을 수 있습니다. 레벨 1 캐시는 사용자가 로그인하지 않고 홀 펀치를하지 않기 때문에 카트에 아무것도없는 경우에 사용됩니다. 이러한 조건 중 하나가 거짓이면 표준 캐시가 전체 홀 펀칭 지원과 함께 사용됩니다.

우리의 FPC는 쉬운 홀 펀칭이 내장되어 있으며 모든 표준 마 젠토 블록 및 사용자 정의 블록과 함께 즉시 사용할 수 있습니다. 관리자 패널을 통해 모두 구성 할 수 있습니다.

스케일링 문제가 없다면 Redis를 고수하는 것이 좋습니다. 태그 지원 기능이 있으며 느린 백엔드로 파일 또는 데이터베이스를 사용하는 memcached보다 훨씬 빠릅니다. 일관된 태그 및 정리를 원할 경우 여러 웹 헤드가있을 때 데이터베이스와 함께 memcached를 사용해야합니다. Redis의 태그 지원 기능이 내장되어있어 걱정할 필요가 없습니다. 세션에 Redis를 사용할 수도 있습니다.

모든 FPC에 대해 말할 수는 있지만 관리자와 함께 FPC를 저장할 위치를 구성 할 수 있습니다. 기본 Magento 캐시 백엔드를 사용하거나 파일, 데이터베이스, APC, Redis, Memcache 및 최적화 된 파일 백엔드를 사용하도록 사용자 정의 설정을 지정할 수 있습니다.


브라우저에 20ms 미만의 배달을 보증 할 수 있습니다. Magento FPC만이 실제 라이브 상점에서 본 것을 보았습니다.
Melvyn

0

정답이 없습니다. 상점은 3s 미만의 동적 페이지로드와 이상적으로 1-2s의 동적 페이지로드를 가져야하며, 1 초 미만은 필요하지 않으며 주로 마케팅 중심 통계입니다. 아파치는 배우기 쉽고 수행하기가 어렵고, Nginx는 배우기 어렵고 수행하기도 쉽지만, 많은 사이트들이 Nginx로 이동하고 있지만 Nginx를 기반으로 한 고품질 아키텍처를 갖기 위해서는 Magento가 간단하지 않습니다.

다중 서버 Magento 클러스터는 이미 구현하기가 복잡하고 올바른 아키텍처가 아닌 경우 유지 관리가 더 어려우므로 일반적으로 더 큰 클러스터를 사용하여 순위를 포함하여 모든 것이 더 원활하게 실행되도록합니다. 1-2 초 동적 페이지로드를 대상으로 중장기 안정성을 약간 변경하여 표준 설치 구성으로이 작업을 수행하므로 유지 관리가 훨씬 간단 해집니다.

바니시는 다른 것들 중에서도 FPC, CDN이 될 수 있지만 귀하의 경우에는 FPC로 생각하는 것이 가장 좋습니다. FPC는 서버에서 더 많은 방문자를 허용하고 Varnish가 그러한 도구 중 하나 인 빠른 정적 전달을 제공하지만 동적 콘텐츠, 재고 관리, 가격 등 다양한 문제가 있습니다. 비즈니스 구성 방식, 데이터로드 방법, 빈도, 호스팅 유형 등은 방문자에게 정적 콘텐츠를 제공함으로써 비즈니스에 영향을주는 것입니다. FPC 구성을 사용하면 기술적으로 많은 부분을 완화 할 수 있지만 비즈니스 소유자 관점에서는 균형 잡힌 투자 수익을 창출하지 못할 수 있으므로 비즈니스 환경이 복잡해집니다.

FPC는 3 이하의 동적 로딩을 사용하는 경우 마지막 부분이며, 아키텍처는 방문자 요청의 비드를 처리하여 순위에 영향을 미치고 마케팅 및 휴가 급상승을 흡수하며 서버 아키텍처의 복잡성을 추가 할 예산을 갖습니다. 호스팅은 0.5 여야합니다 소규모 비즈니스의 경우 매출의 -1 %가 대부분이 간접적 인 비즈니스 문제를 야기하는 실질적으로 운영됩니다.

결정적인 답변을 찾지 못한 이유는 회사가 공개적으로 게시하고 싶지 않은 정보를 요구하는 정 성적 (비즈니스 기반), 페이지로드 속도가 정량적 (기술 기반)이기 때문에 이러한 질문에 답변하는 데 몇 개월이 걸리기 때문입니다. )를 공개적으로 게시 할 수 있다면 솔루션을 만드는 두 가지를 결합하는 방법입니다.


-2

Magento 페이지 캐시 를 필요에 맞게 사용할 수 있으며 광택과 비슷합니다. 그것은 가장 큰 Magento 상점에서 사용됩니다. 일부 기능 :

  1. 니스와 마찬가지로 요청의 90 %에 데이터베이스 연결을 사용하지 않습니다. 결과적으로 매우 빠릅니다
  2. 제품 인벤토리가 변경 될 때 페이지를 자동 플러시하는 기능이 있으며
  3. 멀티 레이어 캐시이므로 사용자가 로그인 할 때 홀 펀치 기능도 지원합니다 (이러한 요청에는 데이터베이스 사용이 필요함).

멀티 레벨 캐시로서 트래픽이 가장 많은 상점에서도 확장 가능하며 SharkTank (tv show)에 등장하는 상점과 같이 트래픽이 많은 트래픽이 많은 트래픽이 많은 사이트에서 사용되었습니다


이것은 니스 또는 FPC의 사용 여부에 대한 저자의 질문에는 대답하지 않습니다.
Steve Robbins

@extendware 당신은 제품의 저자 일 때 공개해야합니다. 우리는 귀중한 기여를 환영하지만, 명백한 스팸은 환영하지 않습니다.
philwinkle
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.