Drush Scripting? Или пакетный API?


8

У нас есть веб-сайт Ubercart, который ежедневно обрабатывает большие объемы заказов, обрабатывает их и выполняет другие задачи, такие как выставление счетов, маршрутизация доставки и создание будущих заказов.

Некоторые из этих задач тяжелые и иногда приводят к превышению времени ожидания PHP. Есть ли лучший способ выполнить эти задачи, как через Drush или Batch API?

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

Является ли сценарий Drush лучшим вариантом или Batch API? Есть ли учебники, чтобы лучше использовать оба?

Ответы:


13

Я бы не предложил использовать пакетный API, просто потому, что пакетные операции зависят от браузера; если по какой-либо причине происходит сбой браузера или он теряет соединение с сервером, пакетные операции не прекратятся или (что еще хуже) будут зависать. Фактически, чтобы избежать тайм-аутов PHP, пакетные операции заставляют браузер проверять страницу пакета с интервалами; это то, что происходит всякий раз, когда задействован код JavaScript, или нет (в последнем случае Drupal использует метатег обновления).

В этих случаях Drush, вероятно, является лучшим выбором; Вы можете создать собственный модуль, который реализует определенные команды Drush, или просто добавить командный файл в каталог, который Drush использует для своих команд.


2
В дополнение к drush вы также можете использовать очередь для одновременного запуска нескольких элементов.
Даниэль Венер

2

Также вы можете использовать собственный скрипт PHP CLI. Вот простой пример для Drupal 7:

#!/usr/bin/php
<?php
echo "Ubercart tasks\n===================\n";

$_SERVER['HTTP_HOST']       = 'default';
$_SERVER['PHP_SELF']        = '/index.php';
$_SERVER['REMOTE_ADDR']     = '127.0.0.1';
$_SERVER['SERVER_SOFTWARE'] = NULL;
$_SERVER['REQUEST_METHOD']  = 'GET';
$_SERVER['QUERY_STRING']    = '';
$_SERVER['PHP_SELF']        = $_SERVER['REQUEST_URI'] = '/';
$_SERVER['HTTP_USER_AGENT'] = 'console';

define('DRUPAL_ROOT', getcwd());
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
//-------------------------------------------

// Place your code here

4
Проблема в том, что вы изобретаете велосипед. Drush - лучший выбор, так как он уже будет делать такие вещи, а фреймворк уже на месте!
Крис Коэн

1
Я не люблю устанавливать drush на всех серверах, где я хочу что-то делать.
ya.teck

2
Есть ли причина, почему? это примерно так же интенсивно, как установка любого другого модуля.

Я делал это много раз, и я думаю, что этот метод немного проще.
ya.teck

1

У меня есть сайт D6 Ubercart, который требует значительной внутренней обработки для «автоматически генерируемых цифровых продуктов». Я справляюсь с этим через:

  1. Покупка одного из этих пользовательских цифровых продуктов приводит к появлению в таблице базы данных «продуктов, которые необходимо скомпилировать». В этой записи БД есть поле «статус».
  2. Сценарий BASH запускается изнутри Drupal, который работает в фоновом режиме. Этот сценарий является «входящим», что означает, что он осведомлен о том, что его вызывают во время работы, и добавляет новую работу к любой существующей работе, которая еще не завершена.
  3. Этот сценарий BASH увеличивает поле «состояние» в базе данных Drupal по мере создания настраиваемого цифрового продукта, и, наконец, пользователю отправляется уведомление по электронной почте со ссылкой для загрузки готового настраиваемого продукта.

Это в некоторой степени похоже на решение, предложенное Xio, за исключением того, что здесь не используется сценарий PHP CLI, а сценарии BASH, вызываемые PHP в Drupal для запуска в фоновом режиме. Эти скрипты BASH обращаются к базе данных Drupal и повышают значения «статуса» любых продуктов, которые она собирает и отправляет клиентам. Кроме того, Drupal может видеть эти значения состояния и отчитываться перед клиентами, где в «процессе пользовательского создания» происходят их покупки в данный момент.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.