우리는 전혀하지 않습니다. 이제까지. 우리는 이것을 반복해서 말할 것이지만
캐싱! = 성능
FPC를 추가하지 않고도 사이트 가 빨라야합니다. 콘텐츠가 준비되지 않은 시간이 항상 있습니다 (위의 시나리오).
언로드 된 상점에서 FPC를 사용한 페이지로드 시간은 FPC가 아닌 것보다 훨씬 인상적이어서는 안됩니다. Magento는 < 400ms표준 캐시 (카테고리 / 제품 / 검색 페이지) 에서 페이지로드 시간을 매우 즐겁게 해줍니다. FPC는 < 80ms이 문제를 해결할 것입니다. 그러나 경고가 있습니다.
- 무효화 또는 TTL 만료까지 주식 / 가격 정보가 오래되었습니다.
무효화 또는 TTL 만료까지 새로운 품목 /보다 관련성 높은 검색이 오래되었습니다.
기타
FPC (또는 니스)에 대한 의존이 나쁜 생각 인 이유
캐시가 수동으로 프라이밍되는 것을 지속적으로 확인하려는 경우 몇 가지 이유가있을 수 있습니다.
- 캐시를 프라이밍 할 수있는 충분한 여유가 없습니다 ( 'FPC가 유용한 위치'참조)
- 그들없이 당신의 사이트는 너무 느립니다
모든 것을 캐시 할 수는 없습니다
카테고리가 5 개이고 중첩 된 2 개 레벨, 5 개의 필터링 가능한 속성, 5 개의 속성 옵션 및 1000 개의 제품이있는 상점을 이용하는 경우; 그것은 가능한 많은 조합입니다.
선택할 수있는 25 가지 옵션, 한 번에 최대 5 번 선택- 통계학 자는 아니지만 ... (속성 옵션의 수가 완전히 줄어들지 않는다고 가정)
25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5 possible URLs on the fifth selection
5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)
알다시피, 위의 시나리오는 3 번의 클릭으로 고객이 제품을 찾을 수있을 정도로 사용 가능한 제품 수가 충분히 줄어 듭니다. 그렇더라도 ...
25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection
5^3 = 125 possible URL combinations
그런 다음 5 개의 카테고리로 625 개의 URL을 곱합니다. 이 단계에서는 작은 카탈로그에 대해 이야기하고 모든 제품 URL을 완전히 무시합니다.
또한 중첩 범주가 is_anchor켜져 있으면 기하 급수적으로 증가 한다는 점을 고려하지 않았습니다 .
따라서 많은 양의 페이지를 크롤링하려면 페이지로드 시간이 좋고 낮기 때문에 빠른 프로세스 (크롤링의 목적을 어 기고 있음)가되기를 바랍니다. TTL이 만료되기 전에 완료 될 충분한 시간.
페이지로드 시간이 0.4 초이고 8 코어 CPU가 있다면 ...
625 * 0.4 = 250 / 8 = 31 seconds
0.5 분, 나쁘지는 않지만 2 초 페이지로드 시간이 있다고 가정 해 봅시다.
625 * 2 = 1250 / 8 = 156 seconds
하지만 가능한 최대 시나리오를 취했다면
3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes
이것이 15 분 동안 100 % CPU 부하를받는 프로덕션 서버입니다. 원하는 TTL에 비례하여 크롤링 속도를 줄입니다.
따라서 콘텐츠에 3600s TTL이 포함되도록하려면 크롤링 속도가 4 배 느려질 수 있습니다. 크롤링 전용 CPU는 25 %에 불과합니다. 카테고리 콘텐츠를 준비하는 데 도움이되는 많은 리소스입니다.이 단계에서는 제품, 검색어 또는 추가 매장보기를 고려하지 않았습니다.
실제로, catalog_url_rewrites계층 탐색 메뉴에서 매개 변수를 고려하지 않은 표 에서 조합의 단순한 크기를 살펴보면 크롤링해야하는 URL 수에 대한 아이디어를 얻을 수 있습니다.
모든 상점은 확실히 다를 것이지만, 내가 집에들이려고하는 것은 사이트를 크롤링하여 FPC를 프라임하는 것이 실용적이지 않다는 것입니다. 상점이로 빠르게 시작되는지 확인하십시오 .
FPC가 유용한 곳
FPC의 이점은 실제로로드가 많은 상점에서 얻을 수 있습니다. 실제로 트래픽이 많고 캐시는 자연스럽게 지속적으로 시작됩니다.
FPC는 일반적으로 요청되는 콘텐츠의 인프라 오버 헤드를 줄여 Magento 백엔드에 대한 반복 호출을 줄임으로써 작동합니다.
따라서 페이지로드 시간을 줄이려는 것이 아니라 리소스 사용을 줄이려면 트래픽 수준이 매우 높을 때 FPC를 배포하는 것이 좋습니다.
누가 신경 써도 여전히 크롤링하고 싶어
그럼 두 가지 옵션이 있습니다
- 템플릿에서 크롤링 (예 : 사이트 맵)
- 페이지별로 링크를 추출하고 각각 크롤링
그리고이 두 가지를 모두 수행 할 수있는 많은 유틸리티가 있습니다.
- 마법사 성능
- HTTrack
- 너치
- 스파이더
- 크롤러
마법사 성능 테스트
Mage-Perftest로 상점을 크롤링 할 수 있습니다. 먼저 다운로드하십시오.
wget http://sys.sonassi.com/mage-perftest (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386 (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*
그런 다음 Magento 사이트 맵을 사용하여 크롤링 프로세스를 정의하십시오 (URL이 <loc></loc>태그 로 묶인 경우 URL의 사이트 맵을 작성하여이를 사용자 정의 할 수 있음 ). 다음 명령은 사이트 맵 파일에서 모든 URL을 읽은 다음 1440 분 (1 일) 동안 URL을 크롤링 (PHP 만)합니다. 서버가 20 % CPU를 초과하거나로드 평균이 2 인 경우 크롤링이 일시적으로 중지됩니다.
./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2
1 일 동안 크롤링 된 URL이 1000 개인 경우 약 1입니다. 86 초마다 1 회 요청 ~ 0.011 RPS 목표