Количество запросов на главной

[krumax]

С движком знаком недавно и вот сейчас мне стало интересно, какое количество запросов у него на главной странице.

Решил установить счётчик и у меня просто округлились глаза

Сразу предупреждаю, это делалось на на голом движке, и вот что я получил:

Время выполнения: 0.6419 секунд | MySQL: 61 запр.

С интернет-магазинами до этого не работал и поэтому хочу задать вопрос:

Это нормально и по сколько запросов в среднем у других ?

Просто до этого работал с другими движками и помнится, что меня приводило в ужас уже 10 запросов на главной и

и поэтому применялось кеширование.

P.S.

хотя я могу и ошибаться, возможно не там считал )

[ravilr]

https://opencartforum.com/topic/10270-дубли-страниц-seopro/

[krumax]

ravilr

Ну и к чему Ваша ссылка?

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

Ну а сколько у Вас в среднем запросов на главной?

[ravilr]

ну если с кешированием у вас... тогда не знаю что там у Вас. Я лично у себя не проверял... меня это не волнует на данный момент.

[krumax]

Я лично у себя не проверял... меня это не волнует на данный момент.

меня же очень даже волнует, лучше на начальном этапе сделать нормально, чем

потом разбираться почему загнулся мускуль при 10 посетителях онлайн )

[dess81]

Да в Опенкарте все очень плохо с этим делом. При создании 120 категорий и 1000 товаров количество запросов доходит до 450 штук, что уже совсем страшно. Существуют плагины кэширования раздела категорий (тот что слева), что снижает нагрузку до 90-100 запросов (при условии вывода товаров на главной, новинок и прочего). Именно поэтому когда выходит новинка, то прежде всего интересует решили ли эту проблему. Так как покупать плагины кэширования под каждую версию запаришься.

[krumax]

dess81

Спасибо за ответ.

Хотелось бы ещё услышать мнения людей которые участвуют в разработке движка.

[Гість]

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

Если у Вас до 500 уников в день, средняя VDS за 500 рублей будет спокойно держать и без наворотов, максимум индексы в таблицу добавить.

У меня магазин http://procanvas.ru, там не больше двух запросов на страницу, все остальное кэшится.

Сейчас делаю http://menspro.ru при выводе трехуровнего меню на запрос не из кэша делается всего 4 запроса. Что в 10 раз меньше стандарта.

p.s. 50 запросов это фигня.. ух помню на друпале контентные порталы делали, так там 400 запросов - это вообще норма.

[krumax]

Lorigin

ну для меня на TorrentPier 3 запроса норма :-D

А кеширование однозначно буду делать.

[freelancer]

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

так же сам вручную дописывал кеширование в узких местах, html кешировать смысла нет.

[Гість]

так же сам вручную дописывал кеширование в узких местах, html кешировать смысла нет.

как же нет? зачем лишний раз гонять 3-4 вложеных скрипта (я про меню), когда можно закэшировать полный вывод..

[freelancer]

как же нет? зачем лишний раз гонять 3-4 вложеных скрипта (я про меню), когда можно закэшировать полный вывод..

в скорости выигрыш незаметен, но возрастает нагрузка на диск

[Гість]

в скорости выигрыш незаметен, но возрастает нагрузка на диск

дак так мы один фиг берем кэш запроса, а тут сразу берем кэш обработанных данных (к кэшу запросу уже не обращаемся). причем на выходе объем даннных может быть и меньше.

[Yesvik]

p.s. 50 запросов это фигня.. ух помню на друпале контентные порталы делали, так там 400 запросов - это вообще норма.

Счастливый человек... а мне довелось рехтовать магазины на OpenCart в которых более 1500 запросов на страницу было...

А по поводу кеширования рендера менюхи - полностью с тобой согласен, надо делать... правда иногда это накладно и приходится кешировать сформированное дерево и каждый раз рендерить.

[freelancer]

дак так мы один фиг берем кэш запроса, а тут сразу берем кэш обработанных данных (к кэшу запросу уже не обращаемся). причем на выходе объем даннных может быть и меньше.

всё относительно и зависит от конкретной ситуации =)

смотри, например я кеширую меню(то которое с категориями <div id="menu">) на главной оно выглядит так, а в любой категории иначе(подсвечивается выбранная категория class="active")

значит мне нужно кешировать N раз по кол-ву категорий хотя запрос во всех случаях достает из базы один и тот же набор данных

[Yesvik]

в скорости выигрыш незаметен, но возрастает нагрузка на диск

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

[Yesvik]

всё относительно и зависит от конкретной ситуации =)

смотри, например я кеширую меню(то которое с категориями <div id="menu">) на главной оно выглядит так, а в любой категории иначе(подсвечивается выбранная категория class="active")

значит мне нужно кешировать N раз по кол-ву категорий хотя запрос во всех случаях достает из базы один и тот же набор данных

Именно это я и имел ввиду когда писал что иногда приходится кешировать сформированное дерево и при рендере навешивать эктив...

[freelancer]

Именно это я и имел ввиду когда писал что иногда приходится кешировать сформированное дерево и при рендере навешивать эктив...

о_О оно того не стоит..

по порядку

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

я подковырял controller, action, front из system/engine, в controller.php добавил метод prerender, который переопределял в контроллерах, метод сразу же отдавал готовый html из кеша если тот был. переопределение нужно как раз из-за разных параметров в request(category_id для меню категорий и т.п.) баловался с разными модулями пока не заметил что рендеринг довольно быстрый ~0.0001с и в некоторых случаях работал быстрее чем чтение с диска. сервера который бы позволял кешировать в память(memcached) у меня не было под рукой потому оставил это баловство до высоко-нагруженного магазина.

[Yesvik]

о_О оно того не стоит..

На трёх категориях - не стОит, а начиная с пары сотен - ещё как стОит....

Особенно когда одно сформированное дерево используеш и для горизонтального меню и для модуля Категории.

[krumax]

freelancer

вот меня как-раз тоже интересовало кеширование с применением memcached

[freelancer]

На трёх категориях - не стОит, а начиная с пары сотен - ещё как стОит....

Особенно когда одно сформированное дерево используеш и для горизонтального меню и для модуля Категории.

=) сколько времени занимает сам рендеринг, без обращения к базе/кешу, вычислений?

[freelancer]

freelancer

вот меня как-раз тоже интересовало кеширование с применением memcached

на форуме был где-то драйвер, да и написать его дело не хитрое

[krumax]

Попробывал воспользоваться решением описанным ЗДЕСЬ.

UPD:

и только сейчас увидел это :oops: :

https://github.com/ocStore/ocStore

Если хотите включить поддержку Memcache, добавьте в config.php:

define('CACHE_DRIVER', 'memcache');

define('MEMCACHE_HOSTNAME', 'localhost');

define('MEMCACHE_PORT', '11211');

define('MEMCACHE_NAMESPACE', 'opencart_test');

========

Mysql cached:

define('DB_DRIVER', 'mysql_cached');

define('DB_CACHED_EXPIRE', 120);

Для сброса всего SQL кеша можно поместить текущее время time() в кеш с ключом "sql_globalresetcache".

[Yesvik]

=) сколько времени занимает сам рендеринг, без обращения к базе/кешу, вычислений?

Поиграйся с этим кешером cache.zip

Кеширует рендер только для гостей, а их как правило большинство...

Он сыроват и надо допиливать вставку динамических блоков, но посмотреть статистику вывода кешированного рендера - можно.

[freelancer]

Поиграйся с этим кешером cache.zip

Кеширует рендер только для гостей, а их как правило большинство...

Он сыроват и надо допиливать вставку динамических блоков, но посмотреть статистику вывода кешированного рендера - можно.

любопытно