Официальный форум OkayCMS

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

Vladzimir писал(а):замедление выборки из БД при включении кеша мускуля

это как? Кеш же предназначен ускорять выборки

zyxer писал(а):это как? Кеш же предназначен ускорять выборки

А вто так. Я периодически включал кеширование мускулем, и всегда результат был хуже.
Да и кеш самого мускуля деревянный. Он например сбрасывается на всей таблице, если меняется любое значение в ней.
Так что вопрос открытый. Зачем и почему.

давно еще интересовался про Memcache (или Redis) viewtopic.php?f=6&t=922&p=4648#p4648 так и не ответили)

Планируется сделать некий механизм взаимодействия с кэшами, а вот сами реализации будут адаптерами (по типу как ресайз или респонс) Okay\Core\Adapters. Пока самая большая проблема, которая пока не решена - инвалидация кэша. На конкретных проектах делали кэши, но их реализации далеки от приемлемых, чтобы положить в коробку. Если у кого-то есть дельные предложения, давайте обсудим?

А в чем проблема с инвалидацией?
Ставите время жизни кеша, и при его дергании проверяете протух или нет.
Можно конечно реализовать через очереди. Что будет более логично и правильно от "стаи собак".

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

И давайте определимся что имеено мы будем кэшировать? Я вижу кэширование результатов выборок из БД (например список товаров) в зависимости от SQL запроса. Т.е. если мы получили список товаров для категории А отсортированный по имени, эти товары нужно положить в кэш, чтобы в след раз когда будут запрашиваться товары категории А отсортированные по имени доставать их сразу из кэша.

Или вы предлагаете реализовать кэширование как-то иначе?

Кеиширование нужно делать более гибче.
Например меню чтоб каждый раз не генерировать - отдавать вообще html.
Запросы в БД, только те которые не влияют на поведение. Например товар закончился, а в кеше он еще числится что есть.
Одним словом, должен быть модуль с настройками кеша, да и у подключемых модулей должна быть возможность указывать время жизни кеша.
Я например у себя кеширую выборку настроек магазина, меню, и тяжелые выборки (например с этим товаром также покупают). Что-то идет в кеш на час, а что-то и на неделю.
А кому-то вообще пойдет полное кеширование страницы.
Как пища для размышления https://opencartforum.com/files/file/3065-turbo-u ... rt-2x-hhtps-fix-vievedmod-v11/

Vladzimir писал(а):Запросы в БД, только те которые не влияют на поведение. Например товар закончился, а в кеше он еще числится что есть.

вот здесь то и есть основная проблема инвалидации кэша

Vladzimir писал(а):и тяжелые выборки (например с этим товаром также покупают)

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

Само меню закэшировать то конечно не проблема.

На сколько я понял, тот ускорительно для опенкарта кэширует html для каждого урла отдельно?

Да. И части некоторых модулей.
Ну а если хотите делать реально быстрые выборки для фильтра, то вам необходимо смотреть как реализовано в модуле для опенкарта мегафильтрпро.

но кэшировать html для урлов не лучшая идея, т.к. будет кешироваться много бесполезной информации, а кэши тоже денег стоят

Кеш прекрасно жмется без накладных расходов.

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

Вот в теме
viewtopic.php?f=9&t=1916
поставлен вопрос о замере времени исполнения SQL запросов. Ответ ведущего разработчика: по умолчанию в окае такой ф-ции нет.
Как можно что-то делать по оптимизации запросов, если не владеть текущей статистикой их выполнения?

В теме
viewtopic.php?f=9&t=1828&p=8167#p8167
указан конкретный пример резкого падения производительности. Ответа за несколько месяцев не поступило. А при анализе того примера можно обнаружить массу интересного...

korshunov писал(а):Вот в теме
viewtopic.php?f=9&t=1916
поставлен вопрос о замере времени исполнения SQL запросов. Ответ ведущего разработчика: по умолчанию в окае такой ф-ции нет.
Как можно что-то делать по оптимизации запросов, если не владеть текущей статистикой их выполнения?

Так я же написал что есть blackfire и explain (делают разные вещи, но оба помогают отлаживать запросы) или вы это не увидели? :) Ими мы в большинстве случаев и пользуемся.

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

EPLAIN? Я надеюсь вы сейчас не серьезно это сказали.
Каждый запрос ручками мониторить, когда все уже давно используют профайлер запросов?

Vladzimir писал(а):EPLAIN? Я надеюсь вы сейчас не серьезно это сказали.
Каждый запрос ручками мониторить, когда все уже давно используют профайлер запросов?

Смотрите, в соседней теме был задан вопрос "как дебажить sql запросы" я вам назвал свои основные методы. Если вам удобнее профилирование, можно сделать профилирование. Если удобно использовать методы предложенные мной, используйте методы предложенные мной. Тут смотря что именно вы хотите увидеть. Зачастую на проектах включают slow_log и те конкретные запросы, которые туда попали, разбирают через EXPLAIN. Эту практику я перенял у нескольких достаточно больших IT компаний (название говорить не буду) но такой принцип у них работает на highload проектах.

Добавлено спустя 2 минуты 46 секунд:
Еще в Telegram чате OkayCMS задавали подобный вопрос (за профилирование) я предложил такой вариант (не проверял его, просто указал в какую сторону копать):
можно в Okay\Core\Database::__construct() у $pdo вызвать setProfiler или более кошерно можно в Okay/Core/config/services.php где объявлен сервис ExtendedPdo добавить calls где вызвать метод setProfiler приблизительно так: