OC v3.х Увеличение производительности OpenCart и OcStore

  • Автор темы Автор темы Denzy
  • Дата начала Дата начала

Denzy

Злобный самаритянин
Команда форума
Moderator
Разрушитель (V)
Сообщения
412
Реакции
276
Баллы
3 700
Ку чатлане
316748_original.jpg

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

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


Прошу не флудить
 
Universal Import/Export Pro в CSV. Связка Opencart 3.0.3.8 (rs.2) + Journal 3.1.10 Остатки + новый товар, если добавили. По идее импортер просто пропускает товары в которых нет изменений. Слетает, в ручную обновлял фид и тестил.
Скорее всего попросту скидывается кеш самим импортёром. Смотри где в коде это делается и закомменть. Нечего страшного не произойдет если кеш обновится позже
 
Скиллов по коду у меня не хватит)) И кривой фид поставщика тянется только этим имортёром без ошибок и отвалов. Там вопрос решился модулем OpenCart Lightning.
Ок, а как набрать только подгруженному товару кэш?В ручную 9000 - не вариант... Сталкеры это гугл и яндекс боты, они прям сразу недовольны непрокэшированной страницей товара. RocketBoost сыпется на 3000 товара.... кто чем пользуется ?
 
Скиллов по коду у меня не хватит)) И кривой фид поставщика тянется только этим имортёром без ошибок и отвалов. Там вопрос решился модулем OpenCart Lightning.
Ок, а как набрать только подгруженному товару кэш?В ручную 9000 - не вариант... Сталкеры это гугл и яндекс боты, они прям сразу недовольны непрокэшированной страницей товара. RocketBoost сыпется на 3000 товара.... кто чем пользуется ?
Только если запрашивать его при заливке.
 
я тут демо сайт накидал на Luxshop, для объявлений по разработке
так вот у него в стоке, без лишней грязи вот так)

Скрытое содержимое. Вам нужно войти или зарегистрироваться.
 

Вложения

  • Screenshot_2.png
    Screenshot_2.png
    109,7 КБ · Просмотры: 40
я тут демо сайт накидал на Luxshop, для объявлений по разработке
так вот у него в стоке, без лишней грязи вот так)

***Скрытое содержимое***
Счетчики Яшки и Гугла Установлены?
 
Счетчики Яшки и Гугла Установлены?
написал же ДЕМО магазин) тупо установил шаблон, немного сервер поднастроил, кешер поставил. там все от демки. просто сделал как образец для объявления своих услуг. но цифры в стоке радуют. со всем "навесным" может упадет до 93-94, но будет все равно отлично
гугл я не ставлю и на рабочие магазы, он же с нами не дружит, я с ним тоже
а яшку ставишь "устаревший код метрики" и он не влияет на пейджспид
 
NitroPack 3.5.16 с исправлениями от 3.5.17 по ряду устаревших функций, не хватает в нём AMP, т.к. устаревшая версия, но пока лучше под 3.0.3.7 не нашел ...
В активном поиске 3.5.18 Null на просторах интернет ...
Вопрос: кто-то использовал облачный NitroPack ???
В версии 3.5.18 нет никаких новшеств или исправления багов. Из панели модуля убрали таблицу оптимизации и добавили информацию о прекращении поддержки и переходе на nitropack.io
 
У нас магазин, примерно на 900 карточек товара, фотки в jpg, не оптимизированы, висел на хостинге. Пробовали JetCash ставить, Нитропак. По гуглу вообще практически не помогало. После переноса на свой VDS, оптимизации картинок, удалении кучи лишних модулей, скриптов и самое главное, HTML кодов видосов с ютуба, сайт стал на 50% быстрее загружаться и даже чутка пролез органически в поиске. Вывод тут один - не всегда нужно сразу хвататься за модули, стоит иногда подыскать толкового человека, который пересмотрит код и порежет лишнее!
 
Кеш это одновременно и просто и сложно.
Проблема кеша это холодный старт и задержки при его инвалидации.
Идельно кеш должен инвалидироваться и генерироваться в __destruct().
Далее. Если вы запустите профайлер, то он вас удивит тем что запросы к бд составляют очень малую долю. Главными врагом у вас окажется .... события. У меня они лично сжирают 20% времени генерации страницы. Чуть позднее выложу свой хак.
@CAPAXA , подскажи пожалуйста, что там с событиями, это можно как то ускорить?
 
@CAPAXA , подскажи пожалуйста, что там с событиями, это можно как то ускорить?
Ускорить можно, но в двух словах не рассказать. Но даже при оптимизации, события все равно занимают значимую часть времени.
 
Много шаблонов показывают хорошие показатели загрузки, но при наплыве трафика начинаются тормоза. К шаблону это не имеет отношения. Держать ИМ нужно только не на хостинге и оптимизировать запросы к БД. Это то, что я делаю в первую очередь. Поиск через сфинкс или мантикору делаю.
 
Ускорить можно, но в двух словах не рассказать. Но даже при оптимизации, события все равно занимают значимую часть времени.
А можно попросить на небольшом примере показать?
Мне посоветовали использовать ещё вот такое
 
Много шаблонов показывают хорошие показатели загрузки, но при наплыве трафика начинаются тормоза. К шаблону это не имеет отношения. Держать ИМ нужно только не на хостинге и оптимизировать запросы к БД. Это то, что я делаю в первую очередь. Поиск через сфинкс или мантикору делаю.
А есть готовое решение для мантикоры?
 
не реклама. пользую давно Lightning
Много мнений по этому модулю. Как по мне - поставил - заплатил - работает - забыл.
 
Перевод из FAQ по NitroPack

... как только покупатель добавляет товар в корзину, входит в систему или добавляет товар в список желаний, веб-сайт снова начинает работать медленно. Это ошибка?

Это не ошибка. К сожалению, система OpenCart не позволяет проводить оптимизацию в следующих случаях:
  1. Клиент вошел в свою учетную запись OpenCart
  2. У покупателя есть товары в корзине
  3. У клиента есть товары в списке желаний
При выполнении любого из вышеперечисленных условий оптимизации NitroPack не вступают в силу. Мы рассматривали возможность оптимизации в этих случаях, но в прошлом столкнулись с некоторыми очень серьезными препятствиями:
  1. Место на диске веб-сайта быстро закончится, потому что теперь кешированный контент должен создаваться для каждого отдельного сеанса пользователя.
  2. Частичная оптимизация не работает, потому что содержимое сеанса пользователя изменяет заголовок, и всю страницу нужно оптимизировать целиком, а не частично.
  3. Ваша квота на оптимизацию услуг очень быстро иссякнет.
  4. Это не очень полезно для клиентов, так как их посещение первой страницы всегда неоптимизировано, пока они не решат обновить страницу. Типичный путь клиента с сеансом использует каждую страницу только один-два раза. Это устраняет необходимость в оптимизации.
Немного бредово написано.
Чтобы спать был быстрым в любых условиях, нужно:

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

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

- кешировать категории: дочерние категории, список товаров на первой странице, хлебные крошки, описание, картинки.

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

Чем меньше чтений файлов кеша, тем лучше.

Я себе это все написал, все работает прекрасно и молниеносно быстро. Никакие модули не нужны. В сумме с тем, что я выпил нахрен jquery и bootstrap и переписал запросы в БД система получилась экстремально легкой - 25 КБ несжатого js и 20 КБ CSS, это со слайдерами, адаптивностью, доступностью для незрячих людей и всем, что я только смог придумать. При этом по Lighthouse все метрики 100/100.

Да, писал я долго, полгода где-то, но результат шикарный.

Разве что ещё можно настроить кеш запросов nGinx, но в этом не вижу необходимости, кто хочет - сам себе настроит.
 
Разве что ещё можно настроить кеш запросов nGinx, но в этом не вижу необходимости, кто хочет - сам себе настроит.
Это наиболее правильный путь, который позволяет держать 1000 запросов/сек без потери скорости отдачи. Но там есть несколько подводных камней.
 
Это наиболее правильный путь, который позволяет держать 1000 запросов/сек без потери скорости отдачи. Но там есть несколько подводных камней.
Думаю, если клиенту нужен сайт с 1000 уников в сек, то он не доверит разработку фрилансеру, каким бы умным и опытным я не был.

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

Такие клиенты отлистают бабла именитой фирме с барбершопом и менеджерками и им будут показывать успехи на канбан доске и опережение графиков отставания. Ну как обычно, короче
Как раз это и нужно обыкновенному сайту, от любителей недоддоса и других мамкиных хацкеров. И даже если у вас нет такого количества посетителей, то все равно 99% нагрузки дают люди которые у вас ничего не покупают. Т.е. большая часть запросов даже не доходит до php и разваливается самим nginx. Ну и скорость отдачи практически как статика.
 
Назад
Верх