Как IP.Board реализует механизм выполнения сервисных задач по расписанию ?

 

С кроном всё понятно. Но IP.Board запускает задачи через собственный механизм.

 

Как я делал у себя на сайте: в основном скрипте (который не должен ждать долгих операций) асинхронно вызываю wget, которому передаю адрес служебного скрипта (выполняющего длительные операции). В итоге основной скрипт не ждёт завершения команды wget, а служебный скрипт в отдельном потоке работает сколько нужно.

 

Как это реализовано в IP.Board ?

Как IP.Board реализует механизм выполнения сервисных задач по расписанию ?

Как и во всех кмс, при заходе пользователя на форум запускается функция отвечающая за обработку задач, она смотрит какие задачи нуждаются в запуске и запускает их. В IPB она запускается при запросе браузером адреса, который прописан в исходном коде как изображение, таким образом достигается эффект "асинхронности". Здесь никаких новых решений нет, сделано просто, чтобы не было проблем с запуском задач.

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

 

В коде страницы это изображение можно найти как (в зависимости когда будет запуск следующей задаче по task_next_run)

 

<img src='http://site.ru/index.php?app=core&module=task' alt='' style='border: 0px;height:1px;width:1px;' />

Хитро придумали. Правда, этот способ не будет работать при удалённом выполнении операций (когда от сервера нужно получить определённый ответ без рендеринга полученного содержимого), но для форума такие ситуации исключены.

 

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

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

 

 

Но выглядит не совсем красиво (похож на заплатку).

Самый оптимальный вариант (если говорить о универсальности). Остальные еще больше на костыли похожи.

Самый оптимальный вариант (если говорить о универсальности).

Оптимальный для независимых third-party-движков (CMS, форумы).

 

Всё-таки на каждый запрос веб-страницы приходится ещё один запрос, сопровождающийся инициализацией движка (как минимум, загрузка классов базовой объектной модели). А это дополнительные затраты памяти, ресурсов процессора и файловой системы. Поэтому, в случае, когда используется выделенный сервер или VPS, для выполнения собственных задач лучше воспользоваться кроном.

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

Это изображение появляется в исходном коде только тогда когда нужно запустить очередную задачу

Один лишний запрос к БД ?

 

...но с ним много мароки.

А именно ?

Один лишний запрос к БД ?

task_next_run - время запуска следующей задаче, находится в кэше.