memcache와 함께 Magento EE 1.11을 실행하고 있습니다. memcahce 서버 당 2GB, 총 4GB. 우리는 약 240k 제품이 있습니다.
- 사용 가능한 램 : 6GB
- 핵심 : 16
- 글 : 32
여기서는 더 많은 신제품이 추가되고 매일 제품이 변경되며 백엔드에서 신제품이 추가 / 수정 될 때마다 캐시, 특히 ‘전체 페이지 캐시’가 무효화됩니다.
Magentos 자동 캐시 생성이 활성화되면 크롤러에 8 개의 스레드가 할당되어 캐시를 빌드하는 데 약 2 일이 걸립니다. 2 일 후 memcache는 2 개의 램 디스크간에 분리되어 약 2GB 정도 뜹니다.
문제는 매일 제품을 수정하면 캐시가 무효화되고 ‘전체 페이지 캐시’가 새로 고쳐지면 2GB의 캐시가 다시 정사각형 1로 돌아가고 Magentos Auto 캐시의 점성주기가 다시 시작된다는 것입니다. 이제 캐시가 0으로 돌아올뿐만 아니라 CPU 사용량이 90 %로 급등하고 웹 사이트가 5-10 초 이상 대기중인 게임으로 바뀌며 100 개 이상의 변형이있는 제품을 요청하는 것을 잊어 버릴 수 있습니다. 캐시하지 않으면 처음로드하는 데 몇 분이 걸릴 것입니다.
커뮤니티에 대한 질문입니다.
- 전체 캐시를 다시 작성하고 0부터 시작하지 않고 Magento가 무효화되면 캐시를 자동으로 “업데이트”하는 방법이 있습니까? 캐시가 무효화되면 Magento가 변경 사항을 알고 있지만 캐시의 위치를 정확히 알지 못한다는 것을 알고 있습니다 (잘못된 경우 수정하십시오). 전체 캐시 재 구축을 우회하기위한 모듈 / 구성이 있습니까?
참고로, Tiny Bricks LightSpeed 모듈을 사용하고 있습니다.
-
cronjob으로 Magentos 자동 캐시 생성을 시간 제어 할 수 있습니까? 오후 10시에서 오전 6시 사이에 크롤링을 시작한다고 가정 해 보겠습니다.
-
이 상황에 접근하는 가장 좋은 방법은 무엇입니까?, 매일 기가 바이트 단위로 캐시를 재구성하는 것은 허용되지 않습니다.
답변
RAM이 충분하지 않습니다
우리는 약 240k 제품을 가지고 있습니다
가능한 RAM : 6GB
스레드 : 32
보유한 제품 양에 대한 RAM이 거의 없습니다. 경험상 논리 코어 당 최소 2-4GB RAM을 권장합니다.
가능한 메모리 사용량을 매핑하는 경우 :
max_memory~ 768MB = 24GB의 PHP 스레드 64 개- 240,000 개의 제품은 약 15GB의 InnoDB 테이블 스페이스를 의미 할 것입니다
- 64 개의 PHP 스레드는 약 128 개의 MySQL 연결을 보증하며 일반적으로 최소 연결 당 약 200MB의 비용이 듭니다.
- Redis에서
lzf압축 된 240,000 개 제품의 백엔드 스토리지 및 압축-여전히 약 6GB의 RAM 사용
그래서 지금까지 총 70GB의 커밋 된 RAM이 있습니다. 우리는 심지어 OS 등을 언급하지 않았습니다.
하드웨어가 너무 과소 평가되었습니다 . 이 Magento 서버 설정 기사를 읽고 진행 방법에 대한 약간의 느낌을 얻는 것이 좋습니다 .
Memcached는 캐시 태그를 지원하지 않습니다
Memcached를 사용하는 경우 (문제가 아닌 고성능) 캐시 태그를 저장하거나 저장하지 않습니다. 당신이 가지고 있지 않은 경우 slow_backend는 독립적으로 플러시 할 수 없습니다 – 그래서 당신은 기본적으로 서로 다른 캐시 유형의 구별 할 수없는 캐시를 의미 태그를 저장하지 않는 – 정의.
http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/를 읽어보십시오 .
Redis로 전환하는 것이 좋습니다. 그것은 단점이 있으며 더 큰 상점을 위해서는 상당한 미세 조정이 필요합니다. 그러나 캐시 태그 지원의 실질적인 이점으로 전체적으로 Memcached보다 약간 더 나은 성능을 발휘합니다.
404와 FPC
FPC에는 실제로 문제가 있습니다. 실제로 모든 캐싱 엔진에는 404에 문제가 있습니다. 그 이유는 이전 URL이 여전히 크롤링되거나 연결되어 있기 때문에 전체 core_url_rewrite테이블 을 반복 해야하는 페이지에 도착 하고 404를 포기하고로드하기 전에 정의 된 모든 라우터 및 네임 스페이스와 일치하는 것을 찾아보십시오.
그런 다음 가치가없는 리소스를 캐싱하면 캐시 저장소의 공간이 소모됩니다. 아마도 Memcached 스토리지의 상당 부분이 실제로 404 컨텐츠에 의해 소비되고 있음을 알 수 있습니다.
큰 카탈로그 (240k 제품)를 사용하면 제품 회전율에 대한 공정한 점유율, 즉 URL 변경 및 그에 따른 많은 404를 갖게 될 것입니다.
FPC 무효화 대 청소
현재 그리고 기본적으로 FPC의 동작은 단순히 캐시 항목을 무효화하지 않고 변경 사항에 따라 캐시를 정리하는 것입니다. 우리는 EE 저장소가 필요한 것을 정확하게 수행하도록이 동작을 변경하는 확장 기능을 작성했습니다.
다음은 문제 해결 방법에 대한 아이디어를 제공하는 빠른 패치입니다.
app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
<observers>
<enterprise_pagecache>
<class>enterprise_pagecache/observer</class>
- <method>cleanCache</method>
+ <method>invalidateCache</method>
</enterprise_pagecache>
</observers>
</catalogrule_after_apply>크롤러를 실행하지 마십시오
충분한 거리를 확보 한 경우 크롤링 도구를 실행하지 않는 것이 좋습니다. 불필요한로드가 발생합니다. 사이트를 탐색하는 사람 / 봇 / 크롤러는 캐시를 프라이밍 상태로 유지해야합니다.
그러나 위에서 언급 한 구성 파일을 보면 질문에 대답하기 위해 크롤링 탐색 창에 대해 정의 된 크론 일정이 표시됩니다.
오래된 콘텐츠를 감당할 수 있다면
그리고 궁극적으로 충분한 RAM 이 있다면 . 캐시 된 데이터를 오래 유지하기 위해 FPC에 저장된 콘텐츠의 TTL을 늘리면 이점을 얻을 수 있습니다.
에서 <full_page_cache>태그 당신의 ./app/etc/local.xml바로 정의
<lifetimelimit>86400</lifetimelimit>수명은 초 단위로 정의됩니다. 컨텐츠 신선도, 성능 및 실제로 사용 가능한 스토리지 공간 사이의 균형을 유지해야합니다.
EE와 함께 타사 캐싱 확장을 사용하는 이유
당신은 FPC에 대해 프리미엄을 지불하고 있습니다. 그렇다면 왜 타사 대안을 맨 위에 실행합니까? 제거하십시오.
이렇게하세요 당신의 차가 심하게 달리고 있다면-당신은 보상하기 위해 부팅에 다른 엔진을 추가하겠습니까? 아니면 이미 엔진을 고치세요?
답변
우리는 당신을 잘 이해합니다! 우리는 매일 새로운 제품을 추가하거나 제품을 변경하고 정적 블록도 수정합니다. 그래서 우리는 무효화 된 Magento 캐시로 가득 차 있었고이 상수는 시스템-> 캐시 관리로갑니다. 무효화 된 캐시 유형을 수동으로 새로 고칠 필요성이 싫었습니다.
그런 다음 새로운 Magento Optimizer 확장을 설치했습니다 . 이 모듈은이 프로세스를 자동화합니다. 무효화 / 모든 캐시 유형을 새로 고치거나 지정된 빈도로 Magento 캐시 스토리지를 플러시합니다. 우리 팀 모두에게 진정한 구호였습니다!
이 확장의 또 다른 기능은 X 일보다 오래된 세션 파일과 오류 보고서를 정리한다는 것입니다. var / session 및 var / report 디렉토리의 크기가 기가 바이트로 증가 할 수 있으며 이러한 파일의 수가 백 개를 초과 할 수 있음을 모두 알고 있습니다. 이제 웹 사이트 성능을 늦추기 위해 Magento Optimizer를 한 번 설정하고 이러한 디렉토리를 주기적으로 새로 고치는 것을 잊었습니다.
Magento는 고객이 로그인하려고 할 때 버려진 카트를 현재 카트와 병합하는 것으로 알려져 있습니다. 고객 경험과 충성도 관점에서 볼 때 이는 파괴적입니다. Magento Optimizer 모듈은 X 일이 지난 버려진 카트를 자동으로 삭제합니다. 판매 시간에도이 기능을 사용할 수 있으며 기존 카트가 버려진 시간을 제한 할 수 있습니다.