Импорт 60000 узлов

Question

Я использую Table Wizard + Migrate для импорта узлов в мою установку Drupal.

Мне нужно импортировать около 60 000 вопросов / ответов (они оба являются узлами), и я подумал, что это было бы легкой задачей.

Однако процесс миграции импортирует 4 узла в минуту, и для завершения импорта потребуется приблизительно 11 дней.

Мне было интересно, смогу ли я сделать это быстрее, импортировав напрямую в mysql. Но на самом деле мне нужно создать 60000 узлов. Я предполагаю, что Drupal собирается хранить дополнительную информацию в других таблицах ... и это не так безопасно.

что вы предлагаете мне сделать? Подождать 10 дней? Спасибо

Answer 1

Перенос таблицы должен быть на несколько порядков быстрее.

Вы используете pathauto?

Если да, попробуйте отключить модуль pathauto, что часто вызывает проблемы с производительностью при импорте.

Во-вторых, если отключение pathauto не работает, отключите все ненужные модули, которые у вас могут быть запущены - некоторые модули делают сумасшедшие вещи. Удалите другие модули как источники проблемы.

В-третьих, включен ли журнал базы данных MySQL? Это может иметь большое влияние на производительность - не уровень, о котором вы говорите, а то, что нужно учитывать.

В-третьих, установите xdebug и следите за своим журналом mysql, чтобы точно увидеть, что происходит.

Какой у вас предел памяти PHP?

У вас осталось достаточно места на диске?

Answer 2

Это сложная тема, но в Drupal она очень хорошо освещена. Я не знаю входов и выходов. Но знаете, где искать.

• Data Mining Drupalgroup имеет некоторые советы, знания и информацию по обработке больших объемов данных в PHP / Drupal.
• Ядро Drupal имеет пакетную функциональность , встроенную и называемую BatchAPI К вашим услугам при написании модулей! Рабочий пример см. В этом руководстве по импорту CSV .

Answer 3

Если вы этого не делаете, вы должны использовать drush для переноса узлов в пакетном режиме. Вы могли бы даже написать скрипт для него, если хотите, чтобы он был автоматизирован. Использование командной строки должно значительно сократить время, необходимое для импорта узлов. С помощью скрипта вы можете сделать это автоматизированной задачей, о которой вам не нужно беспокоиться.

Я хочу отметить одну вещь: 4 узла в минуту - это очень мало. Когда-то мне нужно было импортировать некоторые узлы из файла CSV, используя миграцию и т. Д. Мне нужно было импортировать 300 узлов с местоположением, 4-5 полями CCK, и я сделал это за считанные секунды. Поэтому, если вы импортируете только 4 узла в минуту, у вас либо очень сложные узлы, либо происходит что-то подозрительное.

Какие характеристики компьютера вы используете для этого? Где находится источник импорта?

Answer 4

Я просто хотел добавить заметку о том, что отключение pathauto действительно помогает.У меня было импортировано более 22 тыс. Строк, и до его отключения потребовалось более 12 часов, и во время импорта он несколько раз падал.После отключения pathauto и последующего запуска импорта прошло всего 62 минуты и ни разу не произошел сбой.

Просто напоследок, я создал модуль, который перед началом импорта отключил модуль pathauto, а затемокончание подачи, включает модуль pathauto.Вот код из модуля на случай, если кому-то понадобится эта способность:

function YOURMODULENAME_feeds_before_import(FeedsSource $source) {
  $modules = array('pathauto');
  drupal_set_message(t('The ').$modules[0].t(' has been deployed and should begin to disable'), 'warning');
  module_disable($modules);
  drupal_set_message(t('The ').$modules[0].t(' module should have been disabled'), 'warning');
}

function YOURMODULENAME_feeds_after_import(FeedsSource $source) {
  $modules = array('pathauto');
  module_enable($modules);
  drupal_set_message($modules[0].t(' should be reenabled now'), 'warning');
}

Answer 5

У нас была похожая проблема при установке Drupal 7.Оставив его работать весь уик-энд при импорте, он импортировал только 1000 строк файла.

Самое смешное, что точно такой же импорт выполнялся на подготовительном компьютере90 минут.

В итоге мы сравнили исходный код (убедившись, что у нас одинаковый коммит в git), схему базы данных (идентична), количество узлов на каждой машине (не идентично, но похоже)...

Короче говоря, единственное существенное различие между этими двумя машинами заключалось в опции max_execution_time в файле настроек php.ini.

Производственная машина имела max_execution_time = 30, в то время какопытный образец имел max_execution_time = 3000.Похоже, что модуль migrate имеет своего рода систему для обработки «коротких» max_execution_time, что меньше оптимального.

Вывод : установите max_execution_time = 3000 или более в вашем php.ini, что очень помогает модуль миграции.

Answer 6

4 узла в минуту невероятно медленно. Миграция обычно не должна занимать так много времени. Вы можете немного ускорить процесс, используя Drush, но, вероятно, этого недостаточно, чтобы получить разумное время импорта (часы, а не дни). Это не решило бы вашу основную проблему: сам импорт занимает слишком много времени. Затраты на графический интерфейс Migrate невелики.

Импорт напрямую в MySQL, безусловно, будет быстрее, но есть причина, по которой Migrate существует. Хранение базы данных узла в Drupal является сложным, поэтому, как правило, лучше позволить Drupal решить его, а не пытаться выяснить, что и где.

Используете ли вы хуки Migrate для дополнительной обработки на каждом узле? Я бы предложил добавить некоторые записи, чтобы увидеть, что именно так долго. Проверяйте его на 10 узлах за раз, пока не определите задержку перед выполнением целых 60 тыс.