타사 contrib 모듈과 일부 자체 작업 으로이 문제를 해결했습니다. 내 / contrib 배치 작업 속도를 높이는 다양한 방법이 궁금 합니다 .
그들이 노드 (가져 오기 / 업데이트 등)와 함께 작동하고 10,000 + 범위의 노드 구문 분석 목록을 처리한다고 가정합니다 (1,500 만 행을 처리해야했지만.)-그냥 망쳤습니다. .)
drupals cron.php 작업에 첨부하고 "headless"를 실행하는 것이 더 빠릅니까? Drush를 사용하십니까? 또는 이것은 단순히 코드를 개발할 수있는 효율적이고 빠른 구문 분석의 문제이며 외부 영향이나 배치 특정 최적화 팁 이 없습니다 ...
현재 (약간의 계산을 사용하면) 24 시간 이상 걸릴 수있는 작업을 시작했습니다 ...
감사!
답변:
이것은 contrib 코드에서는 작동하지 않지만 코드이고 잘 알고 있다면 drush 명령을 작성하여 작업을 수행하는 것이 좋습니다. drush 내에서 drupal_bootstrap ()을 적절한 부트 스트랩 레벨로 제한 하십시오 . 실제 숫자를 기억할 수는 없지만 모든 drupal 요청에 대해 많은 시간을 부트 스트랩에 사용하므로 많은 시간을 절약 할 수 있습니다.
또한 Migrate 모듈의 내장을 확인하십시오. 나는 그것이 어떻게 모조인지 알지 못하지만 (그런데 시간이 걸리지 않았습니다), 엄청난 양의 노드를 매우 빠르게 타올 수 있습니다.
모든 배치 호출은 HTTP 요청입니다. 따라서 다른 HTTP 요청이 시작되기 전에 처리 할 수있는 반복 횟수를 완벽하게 조합해야합니다. 고려해야 할 두 가지 사항은 메모리와 최대 실행 시간입니다. 느린 배치의 원인 일 가능성이 높은 HTTP 요청 수를 줄이기 위해 배치 당 가능한 많은 반복을 처리하려고합니다.
배치가 너무 무거워서 효율적으로 실행되지 않으면 대신 큐를 사용해보십시오. http://sf2010.drupal.org/conference/sessions/batch-vs-queue-api-smackdown 여기에 좋은 배치 대 대기열 프레젠테이션이 있습니다 . 큐는 사용자 피드백을 제공하지 않으며 병렬로 실행될 수 있습니다.
사용자 피드백이 필요한 경우 배치와 관련이 있지만 배치에서 대기열을 사용하여 최적화하려고 할 수도 있습니다.
병렬로 만들 수 있다면 좋은 시작입니다. 여기에 4 개의 스레드를 사용하여 백만 페이지 이상을 크롤링하기 위해 (부스트를 통해) 내 생각이 있습니다. 지금 일반화하려고합니다. http://groups.drupal.org/node/126624