Як прискорити операції Batch API?

Я зіткнувся з цим як з модулями сторонніх внесків, так і з деякими власними операціями. Мені цікаво, як різними способами пришвидшити мої / contrib пакетні операції ?

Припустимо, що вони працюють з вузлами (імпорт / оновлення тощо), і ми маємо справу з розбором списків вузлів у діапазоні 10 000+ (хоча мені довелося мати справу з 15 мільйонами рядків .. що так - я просто накручений. .)

Чи швидше приєднатись до роботи друзів cron.php і запустити "без голови"? Використовуючи Drush? або це просто питання про те, наскільки ефективним та швидким розбором я можу розробити свій код, і немає зовнішніх впливів чи пакетних конкретних порад щодо оптимізації ...

В даний час я натрапив на операції, які (за деяким приблизним розрахунком) можуть зайняти 24 години…

Дякую!

Це не працює для коду contrib, але якщо це ваш код, і ви це добре знаєте, радимо написати команду drush для виконання роботи. У межах друку обмежте drupal_bootstrap () до відповідного рівня завантаження. Я не можу пригадати фактичну кількість, але дуже великий відсоток часу на кожний друпальський запит проводиться у завантажувальній програмі, і ви можете там заощадити багато часу.

Крім того, перегляньте кишки модуля Міграція. Я не знаю, як це робиться моджо (ніколи не витрачав часу, щоб його пограбувати), але він може промайнути через величезні партії вузлів дуже швидко.

Кожен пакетний дзвінок - це HTTP-запит. Тому вам потрібно знайти ідеальну суміш ітерацій, які ви можете обробити, перш ніж інший HTTP-запит буде звільнено. Дві речі, які слід врахувати, - це пам’ять і максимальний час виконання. Ви хочете обробити якомога більше ітерацій за партію, щоб зменшити кількість запитів HTTP, оскільки вони, швидше за все, є винуватцем вашої повільної партії.

Якщо ваша партія занадто важка для ефективного запуску, ви можете спробувати використовувати чергу. Тут є хороша презентація партії проти черги http://sf2010.drupal.org/conference/sesions/batch-vs-queue-api-smackdown . Черги не надають відгуків користувачів, і їх можна запускати паралельно.

Якщо вам потрібні відгуки користувачів, ви прив'язані до партії, але ви можете навіть використовувати чергу у своїй партії, щоб спробувати оптимізувати її.

Як говорили інші, Друш - це гарне рішення, але черга - чудовий інструмент для використання. Пакетний API в Drupal 7 використовує вбудований основний API черги, тому якщо ви використовуєте MySQL, ваш процес там може бути вузьким. Але API черги Drupal 7 підключений, тому ви можете використовувати іншу систему черг, як beanstalkd.

Якщо ви можете зробити це паралельним, це хороший початок. Ось декілька моїх думок з цього приводу, оскільки я раніше використовував 4 теми, щоб просканувати більше мільйона сторінок (за допомогою прискорення). Прагнучи зробити це узагальненим зараз. http://groups.drupal.org/node/126624