У меня считается, сколько сейчас "воркеров" обрабатывают отложенные запросы оптимизации, и если их уже указанное в настройках число, то новые создаваться не будут.

Откуда ты берёшь эту информацию ?

У меня считается, сколько сейчас "воркеров" обрабатывают отложенные запросы оптимизации, и если их уже указанное в настройках число, то новые создаваться не будут.

новые это в каком контексте? исполнение пыха в кроне не запускаешь?

ты не имеешь доступа к доступу к веб серверу и не можешь оборвать сетевое соединение

Откуда ты берёшь эту информацию ?

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

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

У php вообще нет информации о распределении процессов

Этим занимается mpm в апаче

Ну и скажем так лезть в это не следует

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

давай

интересно

"Оно" ускоряет загрузку сайта на мобильных. В 2008 году мобильным устройствам требовался специальный шаблон, чтобы хоть как-то отображать сайт, и Mobile Joomla 1.0 давала именно эту возможность. Версия 2.0 давала возможность как использовать мобильный шаблон, так и адаптировать имеющийся. В версии 3.0 вся функциональность, связанная с мобильным шаблоном, вынесена в отдельный плагин, зато осталось отличное оптимизирующее ядро, добавлена поддержка PWA и отличный кэш (который стартует до инициализации ядра Joomla и отдает контент без необходимости соединения с БД).

У меня вопрос по кешу, чем твой кеш отличает от скажем полностраничного?

У меня вопрос по кешу, чем твой кеш отличает от скажем полностраничного?

Это кэш такого типа и есть, только в отличие от плагина System-Cache, он начинает работу ДО того, как Joomla инициализируется и подсоединится к базе данных.

Это кэш такого типа и есть, только в отличие от плагина System-Cache, он начинает работу ДО того, как Joomla инициализируется и подсоединится к базе данных.

А что с роутингом?

Про процессы. Mobile 3.0 в процессе оптимизации страницы сохраняет в БД список микро-задач, которые потом нужно будет выполнить (например, оптимизировать изображение, миифицировать js-Файл, скачать файл с удаленного сервера для оптимизации и раздачи его локально, и т.д.). А php-скрипты (в коде они называются "воркеры"), которые их будут выполнять, запускаются или через cron ("php -f /path/to/joomla/administrator/components/com_mobilejoomla/cli/cron.php &" каждую минуту) или через ajax-запрос (index.php?option=com_mobilejoomla&task=cron от каждого посетителя). При запуске каждый воркер в цикле перебирает номера от 1 до N (максимального количества одновременных воркеров, заданного в настройках) и пытается создать файл, имя которого соответствует этому номеру. Если это сделать не удалось (все такие файлы открыты и заблокированы другими воркерами), значит нужное количество воркеров уже достигнуто, и скрипт завершает свою работу. А если удалось, то устанавливаем set_time_limit и memory_limit, и начинаем брать задачи из БД и выполнять их. При этом учитывается, что задача может не завершиться успехом, поэтому считается суммарное количество попыток ее выполнения, и если их стало больше 5, то такая задача помечается как "неудачная" и больше не запускается.

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

А что с роутингом?

Хранится соответствие "исходный нормализованный URL"=>"html-код". Под "нормализованный" понимается, что оттуда удалены utm- и прочие метки. Плюс, проверются куки (например, залогинен ли пользователь).

Хранится соответствие "исходный нормализованный URL"=>"html-код". Под "нормализованный" понимается, что оттуда удалены utm- и прочие метки. Плюс, проверются куки (например, залогинен ли пользователь).

То есть доморощенная замена родному роутингу джумлы Так?

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

а нафига базу напрягать на это?

просто оптимиация изображений

их же тысячи может пойти

сразу

просто елси пустить паука и он сразу по всем пойдет

то как это будет себя ощущать

только вопрос. причем тут ядра процессеора?

как это вообще связано

у тебя крон работает в однопотоке

ну порождаешь ты процессы в линуксе допустим несколько кронов

ну кто сказал что они на разные ядра идут или на одно

а нафига базу напрягать на это?

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

только вопрос. причем тут ядра процессеора?

+

Путаница в терминах

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

ну вообще тогда уж надо завести демона того же, и допустим он с sqlite работает

ну кто сказал что они на разные ядра идут или на одно

Если не заморачиваться с affinity, то linux их сам распределит по ядрам наилучшим образом.

просто хз, в разумнсоти вообще всего подхода в таком виде

Если не заморачиваться с affinity, то linux их сам распределит по ядрам наилучшим образом.

Тогда к чему говорить о ядрах процессора?

ну вообще тогда уж надо завести демона того же, и допустим он с sqlite работает

И требовать от пользователей кроме mysql/pogtgresql устанавливать php-sqlite?

ну и как бы демона тоже отдельно надо запустить =)

и крон твой тоже надо проставить в задачи отдельно

сам ты не пропишешь от пыхи

и тот еж sqlite он идет в стандратных модулях если не ошибаюсь во всех дистрах

Тогда к чему говорить о ядрах процессора?

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

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

Ну это сам сервер решит

Будут или нет

и крон твой тоже надо проставить в задачи отдельно

Да, но это опционально. Можно запускать по ajax, а можно всю оптимизацию делать внутри исходного запроса. Ситуации бывают разные.

то есть загоняем паука

у меня допустим 100к товаров с картинками

робот пошел все гнать

твоя система выдержит это?

как вот будет работать

опиши

все картинки кидаются на пхп скрипт, который кидает в базу микрозадачу

а потом php скрипт в виде аякса еще какой-то или крон запуаскает исполнение микрозадач

так?

твоя система выдержит это?

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

так?

да

Например, у меня двухядерный сервер, я задаю максимальное количество воркеров в 1 и могу быть уверен, что у меня всегда останется свободное ядро для обработки запросов, т.е. такая схема не так сильно повлияет на web vitals, Как если бы все оптимизации делались одновременно и разбросаны по всем ядрам.

ок. денис, понятно

спасибо

Например, у меня двухядерный сервер, я задаю максимальное количество воркеров в 1 и могу быть уверен, что у меня всегда останется свободное ядро для обработки запросов, т.е. такая схема не так сильно повлияет на web vitals, Как если бы все оптимизации делались одновременно и разбросаны по всем ядрам.

гм

Например, у меня двухядерный сервер, я задаю максимальное количество воркеров в 1 и могу быть уверен, что у меня всегда останется свободное ядро для обработки запросов, т.е. такая схема не так сильно повлияет на web vitals, Как если бы все оптимизации делались одновременно и разбросаны по всем ядрам.

А есть сравнение насколько быстрее твой вариант кеша, чем полностраничный джумла?

Это кэш такого типа и есть, только в отличие от плагина System-Cache, он начинает работу ДО того, как Joomla инициализируется и подсоединится к базе данных.

в плагине у тебя? а плагин всегда идет после базы

там любой триггер елси идет, то к базе идет

чтобы узнать включен плагин или нет

даже если у тебя хоть на onAfterInit

поэтому ничем это отличаться от кеша джумлы не будет по сути

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

в плагине у тебя? а плагин всегда идет после базы

У меня кэш запускается хитро, через defines.php в корне сайта.

то естб ты влезаешь в их файлы?

или как

какой механизм

Joomla загружает настройки (пути) из includes/defines.php, но перед этим проверяет наличие файла defines.php в корне, чем я и воспользовался. Конечно, если вдруг у кого-то такой файл есть, то он перезаписываться не будет, но это очень маловероятно.

подожди

как ты запускешь свой код еще раз

я не понял

проверяет, да

и какой мезанизм

Он создает файл defines.php

В корне

@dryabov хорошо, а как ты хранишь файлы?

по какой структуре

я посомтрел, понял про что ты