Чуть может не понял, но приведу рассуждения. Поправь, если я не прав.
Рассматриваю ситуацию, когда базе у тебя 2 000 000 сессий, из них 1 400 000 (70%) — эт боты.
Т.е. симулируется картина, что либо сессии продолжительное время вообще не очищались и накопились, либо у сайта ну очень высокая посещаемость.
В первом случае, если мы поставим limit 5000, то эти сессии удалятся за 280 подходов. Ну а далее у нас будет регулярно все это работать и 2 млн сессий в базе уже не будет. По идее мы должны так сконфигурировать сервер, чтобы каждый раз при срабатывании gc() устаревало не более 5000 сессий, иначе они начнут накапливаться.
Во втором случае (если бешеная посещаемость), хватит ли лимита в 5000 для того, чтобы удалить старые сессии? А если нет — то мы должны повысить лимит.
И у меня возник вопрос: какая разница в обоих случаях, есть лимит или нет? Кроме первых 280 проходов, которые без лимит выполнились за 1 раз (напомню в нестандартной ситуации, что сессии ранее не очищались).
p.s. про smartSessions:
А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить. Я когда это писал все — тормозов особо не заметил, посещаемость сайтов моих была ну до 1000 человек в сутки. Но вообще, поле is_bot реально лучше, ибо в этом случае LIKE поиск убирается, остается просто быстрый поиск по колонке tinyint. В общем если руки дойдут — изменю алгоритм.
На сколько строк таблица сессий набивалась?.. интересно прост :) Я точно не тестировал на объемы, у меня крутиться на сайтах с посещаемостью до 5000 в сутки — это 150 тыс. посетителей в месяц…
Ну и вообще, по поди какой-нибудь индекс нужно добавить или выборку улучшить, наверняка 1 узкое место
Если ты работаешь с miniShop2 и его галереей (я сделал этот вывод, основываясь на том, что речь идет о сниппете mFilter2), то стоит посмотреть на таблицу modx_ms2_product_files и колонку properties: в ней хранятся св-ва изображения. Будет не обязательно дергать физический файл на диске, чтобы узнать размер фото.
Если верно понял, то стоит посмотреть на параметры top и topLevel сниппета pdoField. С его помощью выбрать id корневого раздела и передать в pdoMenu в параметр parents
prepareSnippet стоит, он может поддормаживать
куча tv в фильтре, причем фильтруются как number. Вы же знаете, что tv хранятся в базе в виде строки, и каждый раз при фильтрации они к числу приводятся, что есть медленно
у вас 72 тысячи (!) запросов! есть над чем подумать.
Причин может быть множество.
Нужно и структуру каталога посмотреть, и вызов сниппета mFilter2, и чанк для отображения строки с товаром.
После этого изучить формируемый sql запрос, что там… Поставьте debugParser для первичного анализа еще.
На ваш вопрос нет однозначного ответа и волшебной кнопки.
mFilter2 может работать относительно быстро с большим кол-вом товаров, но нужно аккуратно его использовать.
валидация предусмотрена как в msCustomer, так и в msOrder
т.е. валидация указывается в вызове сниппета.
Сохраниться ли сценарий, что для разных способов доставки я смогу сделать: через курьерскую службу обязательным полный ФИО + мобильный телефон, а для самовывоза просто Имя (телефон не обязателен).
Пример абстрактный, но суть ясна.
На данный момент помощь именно разработчиков мне не нужна, хотя нужно признать, что наши топовые разработчики помощь предлагают почти все.
Все равно предложу еще раз) есть время и желание помочь, прежде всего с целью ускорить выход альфа версии.
Переживания, что другой человек сделает не так, как видишь ты в голове — понятно. Но всегда можно обсудить список задач и подход к их решению. ;-)
Нашел, исправил) обновил пакет в modstore.pro.
У меня он выложен еще в modx.com, но у них настолько глючный репозиторий… я уже 3 раза писал им по поводу критичных ошибок, из-за которых просто невозможно выложить пакет — но воз и ныне там, я не могу выложить обновление.
Значение параметра не обрабатывается парсером, а просто заменяются плейсхолдеры.
Рассматриваю ситуацию, когда базе у тебя 2 000 000 сессий, из них 1 400 000 (70%) — эт боты.
Т.е. симулируется картина, что либо сессии продолжительное время вообще не очищались и накопились, либо у сайта ну очень высокая посещаемость.
В первом случае, если мы поставим limit 5000, то эти сессии удалятся за 280 подходов. Ну а далее у нас будет регулярно все это работать и 2 млн сессий в базе уже не будет. По идее мы должны так сконфигурировать сервер, чтобы каждый раз при срабатывании gc() устаревало не более 5000 сессий, иначе они начнут накапливаться.
Во втором случае (если бешеная посещаемость), хватит ли лимита в 5000 для того, чтобы удалить старые сессии? А если нет — то мы должны повысить лимит.
И у меня возник вопрос: какая разница в обоих случаях, есть лимит или нет? Кроме первых 280 проходов, которые без лимит выполнились за 1 раз (напомню в нестандартной ситуации, что сессии ранее не очищались).
p.s. про smartSessions:
А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить. Я когда это писал все — тормозов особо не заметил, посещаемость сайтов моих была ну до 1000 человек в сутки. Но вообще, поле is_bot реально лучше, ибо в этом случае LIKE поиск убирается, остается просто быстрый поиск по колонке tinyint. В общем если руки дойдут — изменю алгоритм.
На сколько строк таблица сессий набивалась?.. интересно прост :) Я точно не тестировал на объемы, у меня крутиться на сайтах с посещаемостью до 5000 в сутки — это 150 тыс. посетителей в месяц…
Ну и вообще, по поди какой-нибудь индекс нужно добавить или выборку улучшить, наверняка 1 узкое место
Там используется github.com/serbanghita/Mobile-Detect, который в последнем релизе php 8 просит…
php.watch/versions/8.2/dynamic-properties-deprecated
modx 2.8.x стабильно работает на php 7.4
imagick мощнее
c gd всегда были траблы с разными форматами, прозрачностями, наложением масок и т.п.
куча tv в фильтре, причем фильтруются как number. Вы же знаете, что tv хранятся в базе в виде строки, и каждый раз при фильтрации они к числу приводятся, что есть медленно
у вас 72 тысячи (!) запросов! есть над чем подумать.
Нужно и структуру каталога посмотреть, и вызов сниппета mFilter2, и чанк для отображения строки с товаром.
После этого изучить формируемый sql запрос, что там… Поставьте debugParser для первичного анализа еще.
На ваш вопрос нет однозначного ответа и волшебной кнопки.
mFilter2 может работать относительно быстро с большим кол-вом товаров, но нужно аккуратно его использовать.
Рад активному пользователю =)
Спрошу про валидацию.
Ты пишешь:
т.е. валидация указывается в вызове сниппета.
Сохраниться ли сценарий, что для разных способов доставки я смогу сделать: через курьерскую службу обязательным полный ФИО + мобильный телефон, а для самовывоза просто Имя (телефон не обязателен).
Пример абстрактный, но суть ясна.
Все равно предложу еще раз) есть время и желание помочь, прежде всего с целью ускорить выход альфа версии.
Переживания, что другой человек сделает не так, как видишь ты в голове — понятно. Но всегда можно обсудить список задач и подход к их решению. ;-)
Стоит проверить не включено ли этой в настройках хостинга или в файле htaccess
У меня он выложен еще в modx.com, но у них настолько глючный репозиторий… я уже 3 раза писал им по поводу критичных ошибок, из-за которых просто невозможно выложить пакет — но воз и ныне там, я не могу выложить обновление.