일반적인 색인 문제에 대한 영구 솔루션

우리는 큰 재고 기록을 가진 일부 마 젠토 프로젝트를 개발했으며 항상 평평한 테이블을 자르고 CLI를 사용하여 색인을 다시 작성하고 인덱싱이지만 인덱싱 문제가 발생하는 일상적인 두통입니다.

우리는이 문제에 대한 영구적 인 해결책을 찾고 있습니다. 프로젝트를 수행하는 동안 매일 제품을 업데이트하거나 매일 다른 피드에서 제품을 가져 오는 것과 같은 다른 시나리오가 있습니다.

이 방법이나 일부 해결 방법으로 모범 사례를 가진 사람은 많은 사람들에게 감사의 말을 전하십시오.

어떤 인덱스가 느리고 왜 그런지 이해하는 것이 중요합니다

카탈로그 복잡성과 궁극적으로 상점 아키텍처는 기본 인프라와 결합하여 재 색인에 걸리는 시간을 결정합니다.

• 50,000 개의 제품과 10 개의 상점보기가있는 경우 몇 백만 개의 행 catalog_url_rewrite을 처리하는 데 시간이 걸리는 것을 보장 할 수 있습니다 .

• 제품이 100 개이지만 속성이 5,000 개인 경우 catalog_attributes또는 catalog_product_flat테이블을 다시 작성하는 데 시간이 걸리거나 얼굴 이 평평 해질 수 있습니다.

• 1,000 개의 제품이 있지만 500 개의 검색 가능한 속성 catalog_fulltext_search이있는 경우 다시 완료하는 데 시간이 걸립니다

당신이 직면하는 각각의 문제에 대한 해결책은 모든 규모에 맞지 않습니다. 이를 지원할 수있는 올바른 인프라를 구축하고 콘텐츠 최신 성 및 성능을 모두 지원하는 재색 인 빈도 / 전략을 사용합니다.

• 프런트 엔드 캐싱을 추가해도 전혀 도움이되지 않습니다
• 상황에서 더 많은 하드웨어를 던지면
• 카탈로그 크기 / 복잡성을 해결하면 도움이 될 것입니다
• 타사 인덱싱 도구를 사용하면 도움이됩니다.
• 특정 색인 외부화 (예 : 검색> SOLR)

특정 인덱스가 필요한지 여부를 평가하는 경우도 있습니다. 플랫 제품 / 카테고리를 사용한다고해서 항상 모든 상점이 더 빨라지는 것은 아닙니다. 우리는 그것이 상점을 훨씬 느리게 만드는 것을 보았습니다. 따라서 성능 전후에 성능을 테스트 한 후에도 고려할 필요가 없습니다.

tl; dr

은 총알 솔루션이 없습니다. 몇 가지 해결 방법이 Sonassi_Fastsearchindex있지만 권장 사항은 카탈로그 검색입니다.

아마도 밤새 실행되도록 예약 할 때 인덱스 업데이트를 비활성화하면 약간의 도움이 될까요? memcached, Redis, APC와 같은 캐싱을 추가하고 Varnish (CE를 실행중인 경우)와 같은 전체 페이지 캐시를 추가하면 시작될 수 있습니다. Varnish를 사용하려면 Nexcess_Turpentinegithub에서 빠른 시작을 찾으십시오 .

더 많은 정보

색인 문제 (특히 catalog_url_rewrites)는 커뮤니티에서 잘 알려져 있으며 문서화되어 있습니다. Magento는 Enterprise 버전에서 이러한 문제를 가장 많이 처리 한 고객이므로이 버전을 처리했습니다. 많은 EE 고객은 10k + 이상의 제품과 여러 상점보기, 웹 사이트 등을 보유하고 있습니다.

그러나 큰 카탈로그와 많은 수의 속성이 있으면 인덱싱에 오랜 시간이 걸리는 위치, 특히 catalog_url_rewrite, product_flat이있을 수 있습니다.이 경우 내 제안은 인덱스 런타임을 수정하지 않는 것입니다. 길이가 아니라 일부 처리 를 오프로드하여 상자가 컨텐츠를 제공하는 대신 인덱싱하는 CPU주기를 소비 할 수 있도록합니다 .

스스로에게 물어볼 질문들 :

• 인덱싱 문제로 인해 비즈니스가 손실됩니까?
• 나는 잃는 건가요 생산성 으로 인해 문제가 색인에?
• 전환이 손실 될 위험이 있습니까?
• 고객이 재고가 부족한 품목을 구매할 위험이 있습니까 (인벤토리 등)
• 카탈로그 가격 책정 규칙이 핵심 비즈니스의 일부입니까?
• 내 사이트 검색 전환율이 표준 (8-10 %)보다 높으므로 색인 생성 기능이 향상됩니까?

이 특정 문제에 대한 실버 총알 솔루션은 없습니다. 솔루션 제공 업체는 고객이 매출과 비즈니스를 가장 효과적으로 개선하고 간접비를 낮추는 결정을 내릴 수 있도록 도와야합니다.

대안

카탈로그 검색 및 계층화 된 탐색을 Solr로 오프로드하십시오.

가로로 크기를 조정하십시오. Apache / nginx 서버를 더 추가하십시오. 더 많은 서버 = 더 많은 동시 처리량. 이것은 1 : 1이 아닙니다. Nexcess에는 성능 및 Apache 구성에 대한 훌륭한 백서가 있습니다. http://www.nexcess.net/magento-best-practices-whitepaper

그리고 니스와 함께하기로 결정했다면 다음을 기억하십시오.

대부분의 Magento 웹숍에서는 Magento 백엔드 인덱스 관리를 사용하기가 매우 어려웠습니다. 이 문제가 자주 발생했습니다. 개발자가 쉘 스크립트를 항상 실행하는 것은 종종 바쁜 일입니다. 일반적 으로이 문제를 영구적으로 수정합니다.

shell / indexer.php> shell / myindexer.php의 새 복사본을 만듭니다.

154 줄에서 shell / myindexer.php를 사용자 정의하십시오.

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

에

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

166 행에이 검사를 추가하십시오

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

전에

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

그런 다음 새로운 쉘 스크립트를 cpanel cron에 추가하여 5 분마다 실행합니다.

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

위의 셸 스크립트는 5 분마다 실행되고 다시 인덱싱해야하는 프로세스 만 다시 인덱싱하므로 서버 CPU에 대한로드가 높아질뿐만 아니라 전체 인덱싱 프로세스는 매우 빠릅니다. 프로세스의 재색 인화가 필요하지 않은 경우 단순히 재색 인화 프로세스를 실행하지 않습니다. 또한 인덱스 관리 페이지에서 재 인덱싱 모드를 "저장시 업데이트"로 설정해야합니다. 모르는 경우 제출 단추 옆에있는 조치> 색인 모드 변경에서이 옵션을 사용할 수 있습니다.

더 많은 데이터 (인벤토리 크기, 방문자, 기계)를 제공 할 수 있는지 말하기는 쉽지만 다음과 같은 가능성이 있습니다.

• Sonassi_Fastsearchindex카탈로그 검색 색인에 확장을 사용 합니다. 제목, 설명 및 sku를 색인화하지만 (내가 생각한 것 같지만) 카탈로그 검색 색인 작성기 시간을 줄입니다.
• 태그 나 제품 속성 등 실행할 필요가없는 인덱서가있을 수 있습니다. 가격, 제품 플랫, 카테고리 제품 및 카탈로그 검색 만 정기적으로 수행하고 나머지는 매일 수행하는 것으로 충분합니다.
• 2 시간마다 외부 시스템과 제품을 동기화하고 그 동안 PHP 스크립트로 색인을 생성합니다. 따라서 특정 시간에 실행하려는 각 인덱서마다 cronjob이 있으며이 cron이 스크립트를 실행하도록합니다. 이는 서버가 수행 할 수있는 작업과 최신 제품 데이터 사이의 가장 좋은 중간에있는 것으로 보입니다.

Magento CE 1.7.0.2에서 실행 중입니다. 그래도 여전히 고통입니다.)

Dnd_Patchindexurl을 사용하여 catalog_url_rewrite 재색 인 시간을 거의 70 %로 줄일 수있었습니다.

사용 중지 된 제품을 제외하거나 눈에 띄지 않는 제품을 제외하여 URL을 만들지 않는 것이 좋은 해결책이라고 생각합니다.

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

후:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

1.9.1.1에 설치했으며 매우 잘 작동했습니다!

Connect http://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/를 통해 설치할 수 있습니다

EE 1.13으로 업그레이드하십시오. 이 버전에서는 인덱서가 크게 향상되었습니다.