1.2.x Отвязка планировщика в XenForo

Для повышения производительности можно отвязать запуск назначенных заданий и обработчиков от посещения страниц сайта в браузере и переложить это на системный планировщик OS который работает всегда.

Отвязка не сложнее предыдущей(для версии <= 1.1.5):

1. В шаблоне PAGE_CONTAINER в самой первой строке вырезаем

Код:

{xen:if $hasAutoDeferred, RunDeferred}

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

2. Натравливаем системный крон на deferred.php который в корне форума на раз в несколько минут. Например так:

Код:

*/5  * * * * /opt/php-cli -f /home/mytestsite.ru/public_html/deferred.php

естественно подставить свои пути к php и к форуму

3. Если у вас в config.php настроено файловое! кеширование, то имя папки где лежит кеш нужно писать либо полностью, либо (если папка с кешом лежит например в internal_data) так:

PHP:

$config['cache']['backend'] = 'File';
$config['cache']['backendOptions'] = array('cache_dir'  => dirname(__FILE__) .'/../internal_data/cache');

что рекомендую.
(с относительным путём не получится - зенд заверещит)

 

при любом использовании консольного пхп, надо понимать, что это не одно и тоже что и веб сервер - это полностью отдельный конфиг со своими настройками и что работает на веб сервере может не работать в консоли.
Также замечу, что деферред - это не только крон (крон просто использует деферред), а и любая отложенная задача.
Поэтому такой отвязкой легко поломать плагин который будет использовать деферед на стороне клиента, а не только в админке, например понадобится перестройка счетчиков или что-то подобное.
Да пока все работать будет, но до тех пор пока не начнут появляться хаки для 1.2 с использованием деферред.
Т.е. надо несколько раз подумать чтобы придумывать себе проблемы, которые реально не дают выигрыша, а глюки добавят с большой вероятностью.

Кстати банально хкеш работает совсем по другому из консоли (вернее можно сказать не работает вовсе).

 

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

Да, об этом уже тоже подумал. Но судя по всему всё работать будет в любом случае. И даже в админке по сути можно вырезать старт deferred. Надо поглубже потестить.
По сути неважно кто подхватит запуск отложенной задачи - системный крон или браузер. Первое даже надёжнее должно быть слегка вроде как.

Ну так это и не для всех, а для тех кому вот впёрло )) Да и кто сказал что выигрыша нет? Равно как и кто сказал что есть глюки? Вооооооот. Так что эта фраза лучше подходит для тех кто не хочет заморачиваться и надо чем то отмазаться.
а глюки надо отловить если появятся. Пока не заметил. В данном деле лучше не гнобление идеи за "возможные глюки" (если они вообще появятся), а доточка идеи с тестами и фиксами ;-)

Ну да. Тоже сталкивался с разницей работы скриптов. Но всё дотачиваемо.

 

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

Просто я реально не вижу профита в изменении логики работы существующего дефереда. Разгрузка сервера - нет, удобство работы - нет, 100% безбажность - нет. Если просто поиграться - то без проблем, т.е. для того чтобы разобраться. А так - назовите реальную причину зачем это может понадобиться?

 

Обычно, когда сервер нагружен не 24 часа в сутки (а это частая ситуация, так как даже в рамках России найдется пара-тройка часов минимальной нагрузки), по крону делают wget нужного адреса своего сервера. Таким образом пользователь даже не заметит, так как на его запросы сервер будет отрабатывать с минимальным временем работы скриптов.
А выполнять скрипты напрямую без веб-сервера будет из серии граблей. Можно, конечно же, но неудобно или не нужно.
Ну а подготовить нужный адрес уже не составляет труда. Зато гарантированно будет работать в окружении сервера. Если правильно сформировать нужную страницу (скрипт), то будет работать движок ксена со всеми плюшками без каких-либо переделок и новых плагинов.

Во всяком случае это будет менее костыльно. В моем понимании это вообще даже не костыль получится, а нормальное решение.

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

 

Бесспорно, нормальное. Просто я заморочен освободить процессор и память на пару тысяч байт кода прогоняя запрос через веб-сервер. Ну да, для прямого запуска скриптов первоначальных шагов для соблюдения правильной работоспособности будет больше, но зато минус шаг.

Может конечно Но не нужет. Линуксоиды обычно знают Конечно же крон под юзера. дефаулт разумеется.

П.С. отошел от темы. Потестил админку при вырезанным деферредом во всех шаблонах. Ну что могу сказать - работало всё. Все обработки с отложками тоже. Даже не знаю что ещё придумать. Системный крон послушно исполняет все задачи движка также без ошибок.. тестим дальше.

 

Форум тестовый на несколько разделов??
Посмотрю когда у Вас будет десятка 2 стилей и около 300 разделов - тогда сразу вопросы о безглючности пропадут. Т.к. деферед используется в активном интерфейсе (т.е. не в фоне, а с участием самого пользователя, с возможностью прекращения длительной операции) в случаях когда операция не может быть выполнена за заданный промежуток времени и это обычно только на больших форумах или когда много стилей. И если полностью выпилить деферед, то тупо нельзя будет запустить ни одну перестройку шаблонов и т.п. Я не говорю уже о том что при редактировании большого списка узлов, администратор просто не будет знать когда произошло окончательное сохранение, а это очень большая вероятность конфликтов в момент перестройки кеша узлов.

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

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

 

Поизучал логику работы. Никаких ошибок и в помине не будет :=) Хоть на десятки тысяч

А вот тут как раз наоборот позволю не согласиться с точностью до наоборот.
Во первых - таймлимит на исполнение деферред-скриптов и так выставлен.
Во вторых - прерывать процесс - как раз верное движение к ошибке.
Не могу написать что в третьих, скорее 2а - планирование исполнения подобных задач сервером - надёжнее, чем если движок надеется на запуск из браузера, который может и отвалиться случайно.

Да ктож его полностью то выпиливает? на ручные операции данная отвязка ну никак не влияет.

Ну это если бы предыдущий пункт не работал (вызов ручных операций) или работал неправильно, то да. :=)

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

_________________________

Небольшие танцы с бубном дальше:
если кто всётаки использует данную методику, можно предложить небольшое улучшение, особенно если системный крон вызывает скрипт запуска реже чем раз в 5 минут (я на раз в минуту дёргаю):
сделать копию deferred.php в корне и назвать например cron.php, но немного подправить в конце:

PHP:

<?php

$startTime = microtime(true);
$fileDir = dirname(__FILE__);

@set_time_limit(300);
ignore_user_abort(true);

require($fileDir . '/library/XenForo/Autoloader.php');
XenForo_Autoloader::getInstance()->setupAutoloader($fileDir . '/library');

XenForo_Application::initialize($fileDir . '/library', $fileDir);
XenForo_Application::set('page_start_time', $startTime);

$dependencies = new XenForo_Dependencies_Public();
$dependencies->preLoadData();

$remaining = false;
do
    $remaining = XenForo_Model::create('XenForo_Model_Deferred')->run(false);
while ($remaining && (microtime(true) - $startTime >= 120));

и дёргать системным кроном уже не через deferred.php а cron.php
этот вариант быстро "доделывает" то, что не вышло сделать с первого раза.
output для системного крона не нужен

 

Сильно извиняюсь, но в случае, когда форум или вообще ресурс является высоконагруженным, то обычно работают напрямую с базой данных, попутно используя транзакции...
Все же Ваш мегакостыль, ИМХО, не нужен. Для простых случаев достаточно встроенного планировщика и, при необходимости, крона с wget. А в сложных случаях - прямая работа с базой данных. Тогда будет все либо работать из-коробки, либо действительно очень быстро и с любым объемом данных, независимо от веб-сервера и т.д.

 

напрямую юзера не будут писать в сокет мускулю sql-запросы. интерфейс для этого всегда есть, в частности - это форум. а форум на php, у которого есть модуль общения с базой. Или "напрямую" - это предложить юзерам ковыряться каким-нибудь hex-редактором в файле базы данных минуя сам мускуль? Слово "напрямую" - всегда подразумевает определённые условия применения.
По поводу "мегакостыля" - я останусь при своём мнении.
Для меня мегакостыль - работа через wget, который зависит опять же от веб-сервера, лишнего звена.
Для меня мегакостыль - надеяться на браузеры юзеров (ещё одно лишнее звено к веб-серверу), с которыми хрен знает чего может произойти.
Так что метод применяемый тут - наиболее "прямой", исключая лишние звенья и "надежды" на веб-сервер и юзеров. Если сервер должен отработать задачи, он их отработает независимо от лишних промежутков, и как следствие освобождает браузер пользователя от лишних обращений и ускоряет работу. Прямее придумать сложно.

Конечно понятно что метод "некоробочный", подразумевает наличие прямого доступа к серверу, условия понимания работы с системными утилитами, специальные настройки php для срабатывания из командной строки и всем подряд он не подходит, поэтому в "коробку" его корректно не впихнуть.

 

Речь шла о планировщике, если Вы не забыли название темы. При чем тут вообще пользователь???

Опять Вы о чем то своем... Еще раз повторюсь - речь о планировщике, поэтому требуется лишь обратиться по нужному адресу (в случае ксеновского планировщика достаточно обратиться к главной форума). И от браузера пользователя, от wget и от расположения звезд на небе здесь ничего не зависит.

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

Да не в этом дело. Просто любое изменение системы (в виде плагинов и т.д.) может привести к проблемам. Поэтому и Ваше решение не все восприняли так воодушевленно, как Вы

А теперь по поводу оверхеда. В свое время понадобилось в одной системе манипулировать некоторыми данными в mysql. Так как изначально это делалось для системы, которая была на php, то, конечно же, на php и написали ряд своих скриптов, выполняемых по крону. После того, как потребовалось увеличить производительность таких операций, пришлось отказаться от запуска php для каждого скрипта. Таким образом просто написали свой демон на том же php, а ему уже подсовывали нужные данные. Хотя для форума это было бы чересчур, но для одной из компонент биллинга это было оптимальным решением.
Если веб-сервер правильно настроен, то он использует кеширование опкода, а также использует постоянные соединения с базой данных. Это позволяет обрабатывать запросы достаточно быстро, да и сервер не сильно напрягается. Естественно, от кривых скриптов это не спасет, но для обычного планировщика этого хватит за глаза.
А wget нужен лишь в том случае, когда нужно через специальную ссылку обращаться к серверу, либо с авторизацией. Ну и в случае, когда пользователи не круглосуточно бывают на сайте (но это обычно касается серверов внутри небольших сетей, которые недоступны снаружи).

 

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

а кто будет обращаться к адресу? Не браузер ли? Не через интернет ли? Не http-запросом ли?

Гм, придумайте метод как планировщик будет манипулировать данными в базе без mysql, php например. Напрямую так сказать, если по вашему.

Согласен. но я и писал - это стоит делать только прямыми руками и с прямыми мозгами.

А вот это уже интересно, готов поинтересоваться как именно сделано, если несложно в личку скинуть. Вызывать скрипты отдельными php-процессами - действительно не наиболее оптимально, лучше передавать томуже fpm через юникс-сокеты задачки.

Ну кеширование с постоянным соединением можно и без веб-сервера обеспечить, опять же интересна реализация с висящим демоном

Опять же можно и без веб-сервера.

П.С. интересно дальнейшее развитие темы с указанными параметрами.

 

Ну, во-первых, это было очень давно. А во-вторых, я руководил процессом, хотя и участвовал в непосредственном написании. В любом случае исходников у меня не осталось. Но примеры легко гуглятся. Вот пример многопоточного TCP-сервера. Хотя в нашем случае было достаточно периодически читать сигнальный файл и файл с данными.