Перейти к публикации
Дизайн и модификация IPS Community IPBSkinsBETA
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...
cyrax_02

IP.Board: алгоритм запуска задач по расписанию

Рекомендованные сообщения

Как 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;' />

  • Upvote 1

Поделиться сообщением


Ссылка на сообщение

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

 

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

Поделиться сообщением


Ссылка на сообщение

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

 

 

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

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

Поделиться сообщением


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

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

 

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

Поделиться сообщением


Ссылка на сообщение

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

Поделиться сообщением


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

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

 

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

А именно ?

Поделиться сообщением


Ссылка на сообщение
Один лишний запрос к БД ?

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

Поделиться сообщением


Ссылка на сообщение

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×
×
  • Создать...