Поиск по сайту

Причин может быть масса от конфига сервера, до тяжелых запросов к бд, проблемы с dns, cdn и тд Возьмем то случай, когда ваш VPS имеет много ресурсов и настроен серьезным специалистом, а значит проблема на стороне опенкарта и плагинов, которые были установлены Обычно первым делом включают лог тяжелых запросов. Опенкарт в момент создания таблицы выбирает тип таблиц ENGINE=MyISAM. Этот тип может блокировать таблицы, именно поэтому в логе можно встретить простейшие запросы выполняющиеся по 2+ секунды. Лучше перейти на innodb. На просторах гитхаба есть скрипт, который поможет сменить движок хранилища, а так же добавить индексы к таблицам. Кстати, индексы он добавляет всем столбцам, которые содержат подстроку "_id" https://github.com/lilalaunesau/opencart-turbo Но одним логом сыт не будешь и поэтому я написал решение, которое покажет время работы каждого контроллера на странице. Предварительно желательно отключить кеширование mysql. За это отвечают такие параметры конфигурации как query_cache_size = 0 query_cache_type = 0 С скрина, который прикреплен к этому посту можно сделать вывод, что менюшка не кешируется и грузится около 640мс Один из моих модулей отрабатывает за 100мс, что тоже не есть хорошо, но с учетом того что на этой странице таблица из 10+ товаров, то норм Футер тоже можно закешировать сэкономив около 300мс Если этот пост набирает 5 комментов, то выложу это решение. Напоследок хочу сказать, что продакшн это святое и любые тесты и замеры нужно делать на дев, тест или локальном окружении под присмотром профессионалов. Если я где-то некорректно выразился, то пишите поправим

Привели мне пациента... 500к товаров 7к уников в день 150к записей в таблице order. Вобщем не ларек. И вот на категории в 50-60к товаров этот не ларек генерится 12 секунд! Не ну а че... Это ж опенкарт... Это ж не годится для больших магазинов. Никто не смог помочь. Как обычно вот эти сказки школотронов от программизма. В среднем страницы загружаются 2-4 сек, делаем быстро.все решаем, получаем 200-400мс, но на больших категориях все равно дичь. Смотрим запросы находим вот такое прекрасное, да еще и дважды инициализируемое: $sql = "SELECT p.product_id, (SELECT Count(op.order_id) AS popular FROM oc_order_product op LEFT JOIN `oc_order` o ON ( op.order_id = o.order_id ) WHERE op.product_id = p.product_id AND Adddate(o.date_added, INTERVAL 30 day) < Now() AND o.order_status_id > '0' GROUP BY op.product_id ORDER BY popular DESC) AS popular FROM oc_category_path cp LEFT JOIN oc_product_to_category p2c ON ( cp.category_id = p2c.category_id ) LEFT JOIN oc_product p ON ( p2c.product_id = p.product_id ) LEFT JOIN oc_product_description pd ON ( p.product_id = pd.product_id ) LEFT JOIN oc_product_to_store p2s ON ( p.product_id = p2s.product_id ) WHERE pd.language_id = '1' AND p.status = '1' AND p2s.store_id = '0' AND cp.path_id = '". (int)$category_id ."' GROUP BY p.product_id ORDER BY ( p.quantity > 0 ) DESC, popular DESC, Lcase(pd.name) DESC, p.date_added DESC LIMIT 0, 3 "; Ржавый фак и Винни-Пух. Это просто какая то жестяная жесть, джоин на джоин на джоин, при чем наборы 60 к товаров, 300 категорий и порядка 10-20к заказов. И сложная сортировка-группировка этого всего по разным таблицам, да еще и по предвычисляемому полю p.quantity > 0 все те школотроны, которые в гугле прочитали страшно умное слово индексы, тут сразу такие присели... При таких запросах индексы в принципе не могут полноценно работать. Вот реально представьте, для того чтобы выбрать 3 самых популярных товара из категории... Вот такое днище... А теперь вопрос знатокам.... А что же делать ? Как оптимизировать эти процессы? Ну кеш вы скажете понятно, но ведь кеш у нас так или иначе должен прогрется для всех категорий, рано или поздно он протухнет, и все равно кому то из клиентов попадется тухлая страница на 10-12сек, да и там не одна не две жирные категории. 7 секунд или 12.. Разницы особой нету. Вобщем задачка со звездочкой. Как сохранить полностью логику этого запроса без изменений базовых таблицы движка и отдать быстро эти данные холодными без всяких кешей ? Если что, мы с 6 сек на этом реализации, получили 0.18 мс.

20 Скачать / Купить дополнение Turbo | Ускоритель Opencart 2.x | HHTPS FIX | VievedMod | V1.1 У вас тормозит магазин? Ваш хостинг гневно шлет письма о превышении нагрузки? Клиенты уходят так и не дождавшись загрузки страницы? Turbo - решит все ваши проблемы в 99% случаев*. Пока что Turbo работает только для версий 2.0.x 2.1.x для версий 1.5.x используйте Turbocache в связке с этим решением Модуль основан на популярном модуле Turbocache а также на opensource решении от budgetneon. Также он использована библиотека MobileDetect Что делает этот модуль и для чего он нужен? Кеширует все повторяющиеся ресурсоемкие элементы системы ( как то верхнее меню, модуль категорий и все стандартные модули) а после этого сохраняет в кеш целиком всю страницу магазина и при повторном обращении по этому адресу, выдает заранее сохраненный контекст. Благодаря чему существенно снижается нагрузка на сервер и увеличивается скорость повторной загрузки страниц для новых посетителей. Демо на реальном магазине: st-sklad.ru Положительные отзывы: ---------------------------------------------------------------------- Огромное спасибо автору, кто еще не уверен скажу , модуль стоит на рабочем проекте, работает шикарно, лучше не бывает, так же пользовался модулем нитро пак и скажу глюков в нем и правда куча, мне в нем нравиться только сжатие картинок , там есть функция, указываешь папку и он сжимает, но база данных там увеличивается на 100% у меня база огромная из за того, что товара 25000 шт, с нитро она нереально огромная. Данный модуль отрабатывает шикарно и без ошибок, ну и поддержка русскоязычная, а это несомненный плюс, Итог модуль стоит своих денег хоть я и клянчил скидку, но и без данной скидки модуль стоит намного больше указанной суммы. ---------------------------------------------------------------------- Отрицательные отзывы: ---------------------------------------------------------------------- Пока нет.... ---------------------------------------------------------------------- Т.е если к вам зашел посетитель на одну страницу и увидел меню магазина, то для всех остальных посетителей, меню уже не будет формироваться запросами в базу данных и оказывать нагрузку на сервер, а загрузится в виде готового набора данных. Это позволяет значительно снизить нагрузку на базу данных на всех первичных генерациях страниц. После этого. Если страница была просмотрена одним пользователем, для вех остальных она уже будет готовая взята из кеша и выведена в браузер, практически без обращения в базу данных. Т.е. дополнение использует двухуровневое кеширование данных, что позволяет высвободить до 90% вычислительных ресурсов сервера. Данное решение является уникальной разработкой команды Opencart.Pro и не реализовано до сих пор ни в одном из модулей оптимизации Opencart. Даже на пустом магазине дополнение показывает прирост производительности в 15 раз http://turbo.opencart.pro/turbo_screen.png Особенности дополнения. Поддержка: - Мультимагазин - Мултивалюты - Мультиязчыность - Несколько групп пользователей - HTTPS протокола - Возможности корректной работы по обеим протоколам!!! v. 1.0 -Полноценное сохранение всех серверных заголовков. -Возможность из админки добавить исключения для запрета кеширования любых контроллеров. -Возможность из админки задать время жизни кеша. -Облегченный алгоритм очистки "протухших файлов". Старые файлы проверяются не при каждой загрузке магазина а раз в час. v 1.1 -Добавлен модуль просмотренных товаров, работающий независимо от включенного глобального кеша. -Добавлен модификатор, исправляющий некорректное кеширование системных файлов, и формирование ссылок домена, при работе с обеими протоколами. -Для модуля просмотренных товаров - уже есть тплки для шаблона Coloring -Добавлена кнопка очистить кеш в админке -Масса мелких багфиксов И самое главное дружит с шаблонами, которые отдают разный контент под разные устройста (типа Journal) а не используют адаптивную верстку. Установка дополнения: 1. скопировать файлы из папки UPLOAD в корневую директорию вашего магазина. 2. задать права 777 для папки system/storage/turbocache. 3. Добавить в index.php в корневой папке вашего магазина после строки. $registry->set('cart', new Cart($registry)); вот такие строки: // Turbo require_once(DIR_SYSTEM . 'turbo/turbo.php'); GLOBAL $turbo; $turbo = new Turbo($registry); 4. Обновить кеш модификаторов в административной части вашего магазина. 5. Запросить лицензионный ключ личным сообщением на торговой платформе у продавца дополнения, либо запросом на почту [email protected], указав номер покупки, ваш ник и домен магазина. 6. Активировать дополнение в настройках модулей административной части вашего магазина. 7. Установить необходимые вам настройки и ввести код лицензии во вкладке лицензия. 8. Если вы используете HTTPS протокол. Загрузите из папки https_fix модификатор. Обновите кеш модификаторов и удалите системный кеш. Дополнительные фунции: Дополнение умеет изменять размер сжатия Jpg и Png изображений (пока эта возможность находится в экспериментальном режиме. В дальнейшем в дополнении могут появится дополнительные возможности для оптимизации оценки GooglePageSpeed). Часто задаваемые вопросы: DEMO => TURBO.OPENCART.PRO Установка и настройка модуля на магазине клиента + 100% от стоимости модуля. При обновлении на версию 1.1 внимательно прочтите инструкцию. Не рекомендуется к использованию с темой Journal. Если после установки модуля нагрузка на вашу систему не снизилась, а быстро стали работать только закешированные страницы, то скорее всего у вас косячные сторонние модули, либо не правильная конфигурация серверного окружения. С такими пациентами - пишите в личку. Ручная оптимизация больших магазинов и тонкая настройка серверов - под ключ. *Для чистого магазина на Opencart 2.x при условии отсутствия сторонних дополнений, существенно потребляющих ресурсы сервера. Добавил snastik Добавлено 04.04.2016 Категория Кэширование, сжатие, ускорение Системные требования Opencart версий 2.0 - 2.1.xIoncubeLoader с поддержкой Ioncube V9.0<PHP 5.3Внимание. Дополнение не будет корректно работать с переименованной папкой администратора. Метод активации Без активации Ioncube Loader Нет ocStore 2.3.0.2.4 2.3 2.2 2.1 OpenCart.Pro, ocShop Не проверялось Обращение к серверу разработчика Нет

После предыдущего поста, меня закидали тапками, мол ты же сам имеешь отношение к turbo модулю. И бла бла бла.. А вот все остальное поливаешь грязью. И так далее. Мол кто-то где-то мздит. Давайте расставим все точки над i. Турбо разрабатывался в формате решения вопросов с дефолтным опенкарт и на момент его создания решал очень много вопросов. Сегодня, с появлением быстрых хостингов, с тем, что разрабы стали меньше тупить, возможно делать на холодную быстрые магазины, которые в целом не намного медленнее работают без каких-бы то не было глобальных кешей html-контента. Вот например ответ сервера у хорошего магаза, у которого все страницы работают быстрее чем 99% покупателей джект кеша. Чем меньше у нас кешей -тем более актуальные данные. Чем более актуальные данные - тем лучше мы торгуем. Но... есть два момента, давайте разберем каждый отдельно Требования google pagespeed. Уже с год, гугл поменял алгоритм оценки качества страниц, и вес оценки времени генерации страниц несколько нивелировался, и начали учитываться такие факторы, как-то количество внешних скриптов, размер контента на странице, количество элементов DOM и вот это все что вы видите в результатах оценки на странице pageSpeedInsights. Есть у нас известные в узких кругах фантастичесие бизнесмены от бога, которые решили, что они ща вот напишут скрипты автоматизации, обьединения, сжатия, откладывания загрузки контента на странице и заработают свой первый ярд. Ну и да.. Показывают клиенту богатую зеленую пузомерку в pagespeed, а то что весь контент развален, аналитикс и метрика работают как попало, пользовательские метрики через одно место. Их не волнует - главное что вы им заплатили за их уникальные поделки, и вам показали красивую картинку. С таким же успехом, можно каждому сделать вот так, как у господина @spectre и начать лечить геморрой огурцом! https://developers.google.com/speed/pagespeed/insights/?hl=ru&url=https%3A%2F%2Ffreelancer.od.ua%2F А еще специалисты делают инлайн скриптов-стилей в тело HTML, я своими глазами видел 5Мегбайт код HTML на странице! 5 Мегайбайт КЭП! А еще, рассказывают с пеной у рта, что изображения webp ничего не дают. Ну да ну да. Экономия в 30-40% на статике - ничего не дает! А еще вставляют пауков, которые обходят в фоне страницы сайта генерируют кеш(ага ага, на какие нить 20 000 страниц, сутки ходим), все уже десять раз протухло. Воруют друг у друга решения (типа как маркукша у ситикриатора webp компрессор). И бесконечно несут какую-то дичь. Лишь бы с очередной жертвы маркетинга купить себе бутлочку коньяка. К сожалению это данность и эксперность нашего сообщества хоть и растет по чуть-чуть, но все еще находится в зачаточном состоянии. Но есть новая надежда, что таки когда пейсателей идиотики будут закидывать мокрыми тряпочками, они будут внимательнее в своих решениях. Так что к сожалению или к счастью для избранных, автоматизация повышения качества страниц для оценки GooglePageSpeed - это миф из Нью Васюков. А вот второй процесс, от которого есть действительно толк называется: Большие магазины и сглаживание пиковой нагрузки. Представьте себе, у вас 20-30 к посетителей в день. В пик к веб-серверу приходит несколько десятков запросов в секунду на генерацию динамического контента. И у вас может быть мега быстрый сайт, но для того чтобы такое держать стабильно - необходим запас мощности и быстрый сервер и это дорого. Представьте, что у вас основной трафик идет на 10-15 страниц от всего сайта. И вот для того чтобы не тратить лишние деньги на серванты, мы совершенно спокойно, можем приземлить весь активнй трафик на готовые закешированные HTML страницы и надолго отсрочить миграцию на более жирные ресурсы. И вот в таком случае. Нормальный html full кеш мастхев. И только в таком случае!!! Во всех остальных стоит озаботиться сперва быстрой генерацией на холодную! Потому что краулинговый бюджет, быстродействие для залогиненных пользователей и вот это вот все! Но как правило если у вас магазин на холодную туп, хоть десять кешей поставьте, когда появляется активная пользовательская сессия (например добавленный товар в корзину) золушка превращается в тыкву, и если магаз тупой - он сразу становится тупой. И ваш покупатель остается один на один с белым экраном. Так что господа, пользуйте нормальные хостинги, не покупайте кривые хламушники 9999 в 1, и да пребудет с вами трафик и бабло! p.s. И да.. Господа писатели кешеров. Если вы захотите тут похоливарить, и рассказать что я в очередной раз несу бред. Я готов обсудить... Если вы мне покажите хоть кто-то, подобную динамику роста трафика от ваших решений:

Подскажите пожалуйста, есть магазин, 470 000 товаров в одной категории. На выделенном сервере Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 cores) 16ГБ . У товара 20 атрибутов, - суммарно выходит порядка 10М значений атрибутов (которые надо считать на-лету). Весь каталог работает через промежуточную прокладку в виде Sphinx-демона. Файлы индекса сфинкса лежат в RAM диске в оперативной памяти. (выборка товаров в категории, подсчет количества значений атрибутов в фильтре, все все все, что можно крутится на сфинксе) После партицирования индекса на 8 частей и перенастройки конфигурации демона для использования всех 8 ядер процессора, удалось снизить время реакции фильтра с 5 до 1-1.2сек. Среднее время генерации страниц в районе 600мс. При переходе на php7.2 - будет порядка 400-450. Владелец магазина возмущается, ему не достаточно скорости. Подскажите, что можно сделать для ускорения магазина?

14999 Скачать / Купить дополнение Оптимизация и настройка скорости загрузки магазинов Комплексная оптимизация скорости загрузки и отдачи контента магазина. Комплекс мероприятий, направленных на уменьшение ttfb проекта, повышение оценки GooglePageSpeed и стабильности работы проекта. В большинстве случаев базовых методов услуги достаточно для того чтобы снизить время ответа и нагрузку на сервер в 5-10 раз. Несколько примеров настроенных магазинов: ableflight.ru 7000 товаров Дешевый виртуальный хостинг Timeweb, среднесуточный трафик 500-600 человек. Opencart 1.5. Проведена базовая оптимизация системы и отбиты поисковые боты со страниц фильтра. nbmart.ru 100 000 товаров двухядерный VPS 2000, среднесуточный трафика 2000 человек в день. Opencart 2.1 Проведена комплексная оптимизация системы и сервера, с дополнительным индивидуальным тюнингом сторонних модулей, установлена поисковая система Sphinx. http://vse-footbolki.ru 1 200 000 товаров. Выделенный сервер на Hetzner. Opencart 2.1 Проведена комплексная оптимизация системы с дополнительным индивидуальным тюнингом сторонних модулей, установлена поисковая система Sphinx. Выполнена настройка сервера. Проведена работа по оптимизации MegaFilterPro, Оптимизирована работа seopro, настроен memcache. Проект является по сути агрегатором, с постоянно обновляемой номенклатурой, и соответственно повышенным требованиям к производительности базы данных. Как правило все работы по настройке-оптимизации системы производятся "на горячую", т.е. без какого либо явного долговременного ущерба для работоспособности системы. В случае необходимости временно "положить" проект, работы производятся в ночное время. Базовое время выполнения комплекса работ - двое суток в рабочие дни, в зависимости от загрузки - до семи дней, с момента предоставления заказчиком всех необходимых доступов и согласования комплекса работ после аудита системы. При выполнении всего набора рекомендаций и методов ваш магазина начнут любить как покупатели так и поисковые боты. Услуга в себя включает базовый набор методов оптимизации: Аудит системы Оптимизацию количества и время выполнения запросов в базу данных (более 150 недостающих индексов). При установленном модуле "поставщики" от @usergio индивидуальный тюнинг таблиц модуля (повышение скорости обновления товаров возможно до 10 раз). Установку кеширующего модуля Turbo. Установку при необходимости генераторов карты сайта по крону. Аудит и настройку конфигурации mysql сервера (только на VPS). Настройку http-сервера для корректной отдачи статического контента (повышаем GooglePageSpeed). Настройку отдачи изображений. Чистку мусора от всякого рода ускорителей. Настройку Opcache для PHP-интерпретатора (только на VPS). Рекомендации по выбору серевера/хостинга, в 30% случаев можно за счет оптимизации сменить тариф на меньший без потери производительности. Рекомендации по замене/обновлению сторонних модулей на более производительные аналоги или свежие версии. Анализ/правка robots.txt для минимизации нагрузки от поисковых ботов. Для шаблонов @Katalina правка контроллеров шаблона и внедрение кеширования в них. Проверка настроек модулей/фильтров/шаблонов использующих кеширование и настройка необходимых параметров производительности. Проверка корректных прав на запись у системных файлов. Коррекция кода и правка архитектурных ошибок в ранних версиях MegaFilterPro. для версий 1.5.x: Обновление системных классов работы с базой данных. Установку быстрого класса системного кеширования. Правки кода и избавления от артефактов с подсчетами товаров в категории. Правка архитектурной ошибки в ocstore с некорректным методом getFoundRows. Обновление vqmod до свежей стабильной быстрой версии. для больших магазинов от 50 000 товаров возможны дополнительные опциональные реализации: Так же возможны услуги по установке поисковой системы Sphinx (возможно только на выделенном сервере) с использованием уникального авторского конфига, адаптированного для работы с кирилическими данными (только на VPS). Установка модуля seo_pro без кеширования. Установка memcache в качестве системного контейнера для хранилища данных системного кеша (только на VPS). Перевод генераторов любых фидов в cli-скрипты и генерация их по Cron. Оциональные дополнения: Замена связки apache + nginx на чистый nginx. Перенос изображений на поддомен img. Изменения системного класса формирования превью изображений на библиотеку Imagick. Замена базового хранилища для формирования списков товаров на Sphinx, при отсутствии фильтров в списках товаров. Опциональные задачи, а так же задачи по переносу магазина на другой хостинг, установка/обновление модулей как и сами модули - не входят в стоимость услуги по оптимизации и оплачиваются заказчиком по индивидуальной договоренности, дополнения приобретаются заказчиком у авторов самостоятельно! Отказ от ответственности: Основная составляющая услуги - это комплексный аудит системы, рекомендации по оптимизации и базовый набор методов. Услуга никоим образом не способна повлиять на сторонние сервисы metrika, analitics, etc, которые в силу собственных настроек пессимизируют оценку GooglePageSpeed. Также услуга ни при каких обстоятельствах не предполагает объединение-сжатие-перенос скриптов, так как эти методы в силу особенностей архитектуры Opencart и некоторых модулей приводят к некорректной работе системы. Услуга распространяется на структуру магазина на момент начала работ. Любые внесенные после проведенных работ изменения в код, установленные дополнения, либо их новые версии, могут снизить качество работы системы, никаких гарантий по скорости работы системы с измененной структурой кода или конфигурации серверного окружения, после проведенного комплекса оптимизации не распространяются. Любые последствия, или некорректная работа сторонних дополнений/модулей, не является гарантийным случаем. Гарантия работоспособности распространяется только на базовый функционал классов/методов/дополнений исходного кода движка (opencart, opencart.pro, ocstore). Устранение конфликтов в работе сторонних дополнений, возникших в результате проведения мероприятий по оптимизации - оплачивается заказчиком отдельно. Также услугу не подразумевает какого либо гарантийного-постгарантийного серверного администрирования. Любые некорректные состояния, зависания и нестабильная работа компонентов вашего сервера - является ответственностью хостинг-провайдера и вашего администратора сервера. Бекап системы до проведения работ является целиком и полностью задачей заказчика, в случае необходимости, создание бекапа до проведения работ исполнителем, оплачивается дополнительно. Предварительно невозможно никоим образом предоставить конечные расчетные показатели производительности ни в баллах GooglePageSpeed, ни во времени TTFB, так как эти показатели зависят от огромного количества факторов, часть из которых не связана на прямую с работой магазина. Замер показателей работоспособности системы проводится только собственным профайлером, отображающим время выполнения скрипта и количество запросов, и показателями из консоли Chrome. Любые показатели сторонних метрик типа Gmetrix и аналогов - не рассматриваются и не обсуждаются. Ознакомьтесь пожалуйста заранее с перечнем возможных ситуаций, когда явный результат по оптимизации производительности системы невозможен, либо возможен частично: Использования покупателем услуги шаблонов c themeforest или templatemonster, либо иных других шаблонов или модулей, которые изначально содержат архитектурные ошибки при невозможности оптимизировать их работу базовыми методами. Отказ заказчика менять или ограничивать функционал/шаблон (при необходимости). Отказ заказчика предоставить по первому требованию полный доступ к системе (доступ в личный кабинет хостера, root, ftp, phpmyadmin, аккаунт администратора магазина с полным доступом к системе). Использование дополнений от @sv2109, @Exploit, @louise170. Использование русской сборки Opencart или иных сборок, кроме оригинального opencart, ocstore или opencart.pro. Использование любых дополнений полученных нелегальным путем (варез, фрилансер-поставил) а не приобретенных напрямую у авторов. Использования серверов с большим количеством других аккаунтов (в таких случаях бывает необходим дополнительный тюнинг и настройка сервера, которые не входят в стоимость базовой оптимизации) Использования каких либо дополнений/модулей/функционала, который в режиме реального времени обращаются к сторонним API (парсят цену наличие с донора, обновляют валюты, рассчитывают доставку etc...). Частично возможен перевод таких дополнений на AJAX (опционально). Оптимизация производительности FilterPro возможна частичная при некоторых дополнительных условиях. Использование Ocfilter, так же как и FilterPro подлежит частично оптимизации, но в некоторых конфигурациях может формировать огромную нагрузку от ботов на систему. Оптимизация любых модулей, с частично или полностью закрытым кодом Ioncube. Ни при каких обстоятельства после проделанного комплекса базовой оптимизации и получения заказчиком отчета по результатам аудиты системы, а также в случае частных ситуаций, перечисленных в вышеприведенном перечне, оплата за услугу не возвращается. В случае возникновения частных случаев, приведенных в описании услуги, требующих дополнительной оплаты со стороны заказчика и отсутствии частного взаимопонимания с заказчиком, любые опциональные и иные работы оплачиваются почасово по тарифу 1200 рублей в час. Добавил snastik Добавлено 27.06.2017 Категория Услуги