В CS-Cart есть довольно серьезная проблема кеширования, которую по логике стоило бы оформить в баг-трекер, но по правилам того раздела тема всё-равно будет перемещена сюда.
Суть проблемы в том что в работающих и развивающихся магазинах на CS-Cart фактически нет кеша товаров. Причина заключается в кешировании всех товаров единым фронтом, где любое изменение конкретного товара приводит к сбросу кеша. Если товаров более-менее существенное количество, а магазин работает над контентом то в течении дня происходят десятки, сотни, а быть может и тысячи изменений в номенклатуре. Соответственно кеш сбрасывается в сутки десятки, а то и больше раз. Ну и выходит что большую часть времени страницы открываются впервые. Надо кеширование переделать на постраничное, потоварное. Чтобы при изменениях сбрасывался кеш не всех товаров, а только того, который был изменен. Иначе выходит как-то странно - кеш вроде как и есть, но фактически его нет.
Возьмём небольшой магазин. Предположим, что товаров 20000. Посетителей в сутки 2000, а за рабочий день были внесены изменения в товары… всего 20 изменений за весь день. Как часто при таких вводных посетитель откроет страницу не впервые? Да практически нисколько, может несколько самых популярных товаров несколько раз прогрузятся из кеша. Причем, изменения цен и остатков, судя по всему тожа сбрасывают кеш.
При изменении товара (даже цены) нужно сбросить его страницу, иначе будет устаревшая цена показана. Также нужно изменить все блоки в которые этот товар может попасть (ведь редко когда используется ручное наполнение и мы можем быть уверенными что его там нет). Ну и категории конечно, он же там тоже выводится с устаревшей ценой. Значит, дополнительно сброс кеша всех его категорий и их родительских, вплоть до корня.
У товара были теги? Чистим страницы тегов.
Отойдя от прямого функционала, он мог легко подпасть под любую промо-акцию (или “выпасть” из какой-то), а значит страницы акций и блоки Товар дня тоже долой. Интеллектуальные подборки товаров и прочее…
А если данный товар является частью комбинации других товаров? Тогда ещё сбросить страницы связанных товаров.
Вот примерно в таком ключе нужно убрать значительную часть товарного кеша, но, думаю, я таки что-то пропустил и ещё где-то останутся устаревшие данные и их тоже нужно будет сбросить. Получается что единый сброс решает очень много проблем
Но кеш перестает существовать, вот в чем проблема. А он нужен тем больше, чем больше трафик в магазине. А при текущей ситуации выходит что какой бы трафик ни был - кеша практически нет. Ведь чем больше в магазине трафик, тем вероятно и больше бюджета и возможностей по расширению ассортимента/увеличению качества контента. У меня проблема возникла несмотря на то что контент-менеджеры работают в 1С и выгружают-обновляют товары сразу порциями. Соответственно кеш сбрасывается многократно реже, чем если править всё сразу на сайте. Только это всё-равно 20 раз в день. Если править напрямую на сайте, это будет несколько сотен сбросов кеша в день. Причем изменяются чаще всего новые/второстепенные категории, а сбрасываются то все товары. Соответственно идет большая нагрузка на БД на ровном месте.
Когда-то обсуждали в другой теме. Чем более загруженный проект, тем эффективнее становится кеш. Если на сайте 10 посетителей в день, то кеш и не нужен, если 100 000 посетителей, то даже 10 минут кеша даст множество чтений на одну запись. Суть описал выше, необходимо при обновлении товара угадать все страницы и блоки сайте, где бы он мог появится (причём в 2 стороны, там где он был и там где он появится из-за каких-либо правок) практически невозможно.
Если на сайте 100000 посетителей, скорее всего, над его контентом трудится пара десятков человек. И правки вносятся несколько тысяч раз в день(что, кстати, тоже нормальная нагрузка). Суть не меняется, только масштаб проблемы растет и возможности решения проблемы в лоб через избыточную производительность железа и простую оптимизацию запросов падают. Но при 100к посетителей в сутки, вероятно, уже будет бюджет на то чтобы вообще забить на коробку.
Изменения, если на сайте хотя бы 200 посетителей, ну должен же хоть кто-то купить товар, тем самым вызвать цепную реакцию по сбросу кеша, так как изменяется кол-во товара.
Соглашусь с @ab.developer.inj но есть слабые места по блокам которые разработчикам нужно перепроверить. К примеру зачем обновлять кеш основного содержание категорий, когда обновляется
‘product_tabs’,
‘product_tabs_descriptions’,
Но все равно, это конечно все мелочи если брать вопрос о проблемности фильтров.
Соответственно идет большая нагрузка на БД на ровном месте.
Она все равно большая даже когда все закешировано. Кеш это вообще не решение проблем производительности, сайт должен быстро работать без кеша, здесь такого не будет никогда, достаточно увидеть какие запросы километровые тут строятся.
Увеличить скорость сайта интересно многим. Но интересно за счёт чего. Или в этом и есть ноу-хау?
Кэширование до первой правки или выгрузки товара из 1С, конечно, не совсем устраивает.
