Ещё с месяц назад сталкивался с проблемой тормозов при включённом чекбоксе опции "Отображение кол-ва товаров в категории" для меню, в магазине 30 000 товаров и было дело смирился с проблемой. Однако совсем недавно столкнулся с магазином где 250 000 товаров на опенкарте, стоит подсчёт товаров и никаких тормозов не наблюдается... правда возможно там напрямую прописано в меню кол-во товаров, но сомневаюсь. То что хостинг может решать проблему подсчёта 250т товаров - в данном случае сомневаюсь, мне кажется там используется более радикальный метод, возможно есть модули решающие данную проблему, какие могут быть соображения по решению данного вопроса? Ведь более логично просто напросто дописывать к пунктам меню их кол-во и пересчитывать лишь при создании товаров.
Кеширование. Тормоза есть только при обращении к БД. В случае стандартного кеширования ОпенКарта, кеш живёт один час. Можно увеличить время жизни стандартного кеша или использовать дополнительные средства, например, memcached.
Меня никакое кэширование не спасало, на какую страницу не зайди всё одно - по 3 минуты грузились. Мемкашед на сколько помнится то же имеет недостатки и периодически вешает магазин, да и поставить его можно только на выделенный или виртуальный сервер, хотя на форуме есть "хвастуны" с ехидной улыбкой заявляющие, что способны решить эту проблему за скромное или не очень вознаграждение. Вот и интересно на сколько обоснованы подобные заявления..
Иногда он встречается и на шаред хостингах. А магазин на 250 тысяч товаров на шареде стоять не может в любом случае. Стоит начать с того, что php имеет недостатки Всё зависит от прямоты рук. Не всё попадает в кеш в ОпенКарте. Количество товаров в категории как раз в стандартном варианте не кешируется.
Так тогда можно просто в методе getTotalProducts кешировать данное действо, хотя ... в этом случае кеш создаст 250 000 файлов ...
То есть можно сделать их кэшируемыми? По поводу рук у всех они сначала кривые, все начинают с нуля, потому и советы типа: "пусть делают профессионалы", итак очевидны и потому раздражительны. Кстати, на что влияет подобное вмешательство в код: --- Добавлено, 1 окт 2013 --- А так же может кто-нибудь прокомментировать актуальность следующих действий по оптимизации БД:
Гоню .... Это ж товаров 250000, а категорий-то намного меньше. Ну можно вообще сделать, как говорили ранее (похоже пост зачем-то удалили) - добавить в таблицу categories столбец count (например), в модели products задать изменение столбца count из таблицы categories при добавлении/удалении товара. А в модели категорий в начале метода getTptalProducts поставить проверку, если есть столбец count то тупо берем инфу из него, если нет, тогда считаем А еще лучше: в модели категории к выборке добавляем этот столбец, если он есть, а потом в контроллере при получении ответа смотрим если в ответе этот столбец, если есть то сразу берем, если нет - тогда вызываем getTotalProducts. Так вообще лишних запросов к базе не будет - должно работать с той же скоростью как и при выключенном подсчете
Не создаст. Результат запроса к БД - это один файл. Файлов будет по количеству категорий (на каждую по запросу). А что находиться внутри файлов cache_start.php и cache_end.php? Индексы ускоряют выборку избавляя от необходимости читать таблицу целиком (индексы хранятся отдельно). Но ускоряют они выборку только, если значения более-менее уникальны. То есть, индекс по id товара ускорит выборку, а индекс по статусу, наоборот, замедлит. И есть смысл индексы по полям, которые часто используются вместе делать дополнительно комбинированными (MySQL сам решит по запросу использовать отдельный индекс или комбинированный).
Правильные индексы 100 пудов ускорят, а вот если добавить поле count (ну или по другому его обозвать), то это позволит сделать задержку на подсчет фактически нулевым (просто в запросе на имя, йади и т.д. категории добирать еще и это поле), что значительно лучше, чем просто ускорить
Этот вариант подходит только при добавлении товаров вручную. Кроме того, количество товаров в категории - это не общее количество, а количество включённых товаров. В случае мультимагазина оно ещё завист и от привязки товара к конкретному магазину (категории то могут совпадать).
Согласен - немножко дыряво. Но можно кроном пару (4-6-8) раз в сутки актуализировать цифры через стандартный getTotalProducts Ну а предложенные индексы - во-первых безболезненный вариант в плане реализации и совместимости, во-вторых будет не лишним и при предложенном мною варианте. Так что индексам - да!
