IMDBOptimizer (OC 3) - Оптимизация базы данных. Opencart оптимизация

Ускорение Opencart. Получаем оценку Google Page Speed больше 80

В общих чертах, предыдущие статьи из цикла тормозит Opencart дают достаточно информации, для оптимизации работы движка. К сожалению многие владельцы готовых магазинов оказались в заложниках уже созданного и написанного движка. Любые попытки оптимизировать код запросов, которые априори тяжелые, оборачиваются отказом работы половины функционала магазина, так как денормализуют листинг стандартных файлов, вследствие чего как минимум перестают работать привязки vqmod ов, а как максимум, для того чтобы оптимизировать и ускорить опенкарт до High-load проекта, практически придется написать часть движка заново. У большинства владельцев магазинов нет ни таких ресурсов, и не стоит задача получить систему способную обработать 150 000 хостов день. Как правило основные типовые задачи по отпимизации сводятся к реализации двух результатов: первый — получить время загрузки страницы в пределах одной двух секунд, и второй — получить оценку в Google Page Speed Insights хотя бы 80. Про первую задачу мы уже написали много информации и будем ее дополнять, но к сожалению для реализации второй этих методов недостаточно. И так как практически от каждого, кто приобрел Turbo Cache, приходится слышать одну и ту же фразу «Круто, страница грузится очень быстро, но почему то гугл не среагировал«, давайте попробуем разобраться, почему гугл не среагировал и что делать ?

Начнем по порядку. Наш блог ориентирован на жителей России и Украины, слава богу наши страны находятся практически впереди планеты всей по скорости интернета и для нас большинства ожидание загрузки страницы больше секунды вызывает желание открыть поисковик и поискать альтернативу. В среднем по миру, показатель скорости интернета похуже. Поэтому поисковики в отличии от пользователей при оценке качества загрузки сайта рассматривают комплекс параметров, а не только время загрузки. И даже если мы сделаем очень быстрый скрипт, который будет отдавать браузеру HTML вашей страницы за 50-60 миллисекунд, но при этом вы будете фоном отдавать пятимегабайтную картинку вашей любимой бабушки на новый год, поисковикам это не понравятся. Если честно, я когда вижу на сайте тяжелую фоновую картинку, мне всегда кажется что хозяин сайта не в себе.

Ок. про бабушку — это было лирическое отступление. В реальности, основной принцип оценки сайта поисковиками заключается в следющем: ваш сайт не должен отдавать ни единого байта ненужного байта. Если можно сжат картинки — сожмите, если можно убрать пробелы между тегами HTML и комментарии в нем, убирайте. Для вашего молодого или немолодого сайта разница в длине текста страницы в 1 байт, ощутимо ничего не поменяет. Но представьте ситуацию, с главной страницей Vkontakte например. Вконтакт посещают в день 60 000 000 человек, каждый пользователь грузит 5-6 а то и 10 страниц. Вот и получается что сэкономленный один байт позволяет разгрузить суточный трафик их серверов почти на 3 гигабайта в день. А теперь просто как муравей и океан, представьте количество трафика гугла, который ежесекундно сжирает и обрабатывает огромные массивы информации. Представили, вот представьте, сколько бы серверного времени, атомного топлива на электростанциях и зеленых деревьев было бы сэкономлено, если бы каждый сайт в мире уменьшился на 1 байт. Я не верю в то что корпорация гугл очень уж любит зелень. Вернее они ее любят, но бумажную а не дервянную. Но так или иначе и гугл и яндекс хотят видеть как можно более лакончиный и сжатый контент сайтов.

Вот они и требуют, чтобы ваш сайт не только быстро грузился, а еще и все элементы были по максимуму сжаты, а те элементы, которые не изменяются от загрузки к загрузке, загружались один раз и хранились в браузере у ваших посетителей. На примере — вот логотип сайта, у вас не меняется. А загружается при каждом обновлении страницы. А если у вас настроено кеширование на клиенте — то он загружается один раз, а потом просто выхватывается из локального кеша бразуера. И посетителю приятно, он почти сразу увидел ваш логотип, и серверу легче.

Общей воды я думаю достаточно — теперь давайте перейдем к более предметному рассмотрению. Наши задачи. Сжатие, оптимизация, кеширование на клиенте.

Первое что вам нужно сделать — это сжать и минимизировать размеры статичного контента. Ах да, что же такое статичный контент. Статичный контент — это файлы, которые сохраняются неизменными, независимо от раздела, на котором находится посетитель вашего сайта. Это изображения, JS-скрипты, CSS-стили, текстовые и pdf-файлы и видео контент. Видео и pdf нас неинтересуют, у нас остаются картинки стили и скрипты. Что с ними делать ?

Есть несколько вариантов. Самый идеальный если у вас свой сервер, на который вы можете поставить google modpagespeed. Вникнуть в мануал, или найти админа с головой и заплатить пивом деньгами или натурой за эксперименты. Чуть позже, я возможно выложу оптимальный конфиг для этого мода.И вы получите сразу с сервера правильную отдачу того что вам надо. Здесь нужно сделать оговорку, это работает на nix системах, на freebsd не прокатит.

Второй простой вариант, если у вас нет своего сервера, послать подальше своего любимого хостера и переехать на ukraine.com.ua. Кстати у которого есть сервера в ru зоне. Так что для Россиян нет никаких проблем. И получить на любом виртуал-пакете вот такие возможности, смотим на скрины ниже, тут добавить больше нечего. Но если вы решите купить на Ukraine VPS — придется прибегать к первому варианту.

pagespeed_1 pagespeed2

Третий вариант — прикупить какой нибудь модуль на opencart.com, который делает подобные махинации. Но вам так или иначе придется делать донастройку сжатия и кеширования через .htaccess и не факт что модуль заработает корректно, так как работающих из коробки я еще не встречал. А усилия по установке и настройке, сравнимы с ручным режимом реализации нашей проблемы.

Ну и четвертый вариант. Ручной.

Если у вас чистый Apache без проксирующей заглушки в виде Nginx, для того чтобы установить Gzip-сжатие статики, вам всего то надо подредактировать .htaccess файл, который лежит в корне вашего сайта. Я не являюсь специалистом по настройке серверов, поэтому я погуглю с запросом «настроить кеширование и сжатие на клиенте htaccess». В выдаче на первой странице вываливается чудесная статья с хабра. Читаем. Правим наш файл и идем в pagespeed insights — проверять помогло или нет. Если изменений не произошло, пишем хостеру и матюкаемся.Будем считать, что со сжатием и «кешированием статики на клиенте» у вас получилось, не путать с кешированем данных PHP и запросов в базу данных!!!И после того как получилось у нас чуть поднялась оценка в гугле, но все равно, какие то требования в виде оптимизируйте скрипты, оптимизируйте CSS не пропадают. Гуглим на тему css js optimizer, смотрим в таймлайне загрузки в хроме или фоксе, какие скрипты у нас грузятся, или же в списке, который отдает пейджспид и вручную оптимизируем каждый по очереди. Я пользуюсь вот этим компрессором для JS и вот этим для CSS Тут нужно быть аккуратным, и после каждого оптимизированного обновленного файла обновлять бразуер и проверять сайт на предмет ошибок. Не весь код удается автоматически правильно оптимизировать — это еще один камень в огород сторонних модулей. И кстати, оптимизировать скрипты и стили лучше до настраивания кеширования на клиенте, так как если у вас они в браузере прикешируются, чтобы увидеть изменения вам придется судорожно жать Ctrl + F5.

С этим покончили, идем в админку, в настройки магазина в раздел сервер и задаем уровень сжатия GZIP 9. Если у вас начнутся тормоза после этого бегите с этого хостинга.

Переходим к изображениям. Открываем файл system/library/image.php находим в нем вот такую строку

public function save($file, $quality = 90) {

И меняем в ней параметр качества на 75 или 80. После этого чистите кеш изображений. Если не знаете как — вот вам модуль. Обновляете сайт. И кормите его опять в pagespeed/insights/. На оптимизацию изображений у Гугла после этого должны исчезнуть претензии. Но нужно учесть, что качество изображений визуально для посетителей ухудшиться, поэтому поэкспериментируйте с параметром, чтобы найти баланс между вредностью гугла и приемлемым видом картинок.

С изображениями мы тоже покончили. Если у вас все правильно получилось, то оценка должна быть от 70 до 80. Дальше уже начинаются методы, которые не совсем адекватные, так как их не применяют даже такие монстры как связной или розетка. Но в двух словах. От вас еще потребуют обьединить стили в один, скрипты в один, или сделать асинхронной загрузку скриптов в несколько потоков. И если бы у нас все скрипты модулей в Opencart грузились только в шапке это было бы очень просто, но так как очень много дополнений генерируют и стили и скрипты прямо в HTML, то быстро это не получится. Если все таки 80 вам будет мало. То можете почитать вот это.

P.S. Извините за многобукв, на самом деле тема требует еще более подробного описания со скринами и примерами. Но как мне кажется информации и так достаточно, если что то непонятно или не получилось добро пожаловать в комментарии.

P.P.S. Не забываем ознакомиться с нашей OCSHOP.CMS

Хуйнаныр

(9)Очко

(0)

ocshop.info

Оптимизация opencart

Когда в магазине находится несколько тысяч товаров">> а сам движок не оптимизирован высока вероятность блокировки хостингом, базы данных.

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

Избежать блокировки поможет правильная настройка CMS Opencart.

Прежде всего надо настроить функции PHP. Я не буду в деталях расписывать процесс настройки, потому-что на каждом хостинге разные панели управления. Вы можете обратиться к документации хостинга или онлайн поддержку для включения той или иной функции, настройки PHP.

Для каждого сайта выделяется определенное количество оперативной памяти но не все провайдеры которые предоставляют хостинг по умолчанию включают для вашего сайта весь лимит оперативной памяти. Выясните количество памяти отведенной для вашего сервера, необходимо задействовать весь лимит. Например: Макхост -это выглядит следующим образом:

Оптимизация opencart

В папке admin и корневом каталоге вашего сайта есть файл конфигурации php.ini он предназначен для настройки сервера но есть такой нюанс он будет работать только в том случае если -- Опять все зависит от хостера, если он допускает привилегию пользовательских настроек перед системными, то в нем есть смысл. Если хостер игнорирует пользовательские настройки, то смысла в php.ini нет. однако этот файл следующего содержания:

magic_quotes_gpc = Off; register_globals = Off; default_charset = UTF-8; memory_limit = 64M; max_execution_time = 36000; upload_max_filesize = 999M; safe_mode = Off; mysql.connect_timeout = 20; session.use_only_cookies = On; session.use_trans_sid = Off; session.cookie_httponly = On; session.gc_maxlifetime = 172800; allow_url_fopen = on; ;display_errors = 1; ;error_reporting = E_ALL;

Измените лимит оперативной памяти memory_limit

Читаем дальше поймете для чего все это надо.

в основном сильную нагрузку нагрузку на базу данных создают поисковики в момент сканирования вашего сайта. Это можно изменить в файле robots.txt задав для каждого из поисковиков частоту запросов параметром

Request-rate:

Этот параметр сообщит роботам что они должны загружать «n»-количество страниц за «m»-Секунд

Также можно определить в какое время робот будет посещать Ваш сайт

Visit-time: AAAA-BBBB

Где АААА-это время начала сканирования по Гринвичу и ВВВВ время окончания сканирования. Например разрешим сканировать интернет магазин с 12 часов ночи и до 6.30 утра.

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

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

Теперь поставим модуль NitroPack 1.0.2 для ускорения всей системы я не буду перечислять все его функции их слишком много, поставьте и сами посмотрите.

Самые основные функции это полный контроль кеш памяти оптимизация изображений gСжатие скриптов и CSS файлов, Возможность задать cron очистку файлов кеша, Запросы базы данных , смотрите скрины думаю так понятней будет

В установке данного модуля нет ничего сложного единственное сервер должен поддерживать Memcache или eAccelerator потому что кешировать запросы к базе данных на диск я думаю нет никакого смысла.

А работает ли данный модуль на Opencart 2/0???

-нет не работает, точно работает на 1,5,4-1,5,6 и сборке махi

Внимание! У Вас нет прав для просмотра скрытого текста.

скачать dle 12.0

Нашли ошибку? Выделите текст и нажмите CTRL+ENTER

opencart-help.ru

IMDBOptimizer (OC 3) - Оптимизация базы данных

Название файла	Имя файла	Дата	Действие
IMDBOptimizer(OC3)_1.3.0.zip	opencart_file_7291.zip	2018-06-06 13:06:00	Платный файл

* Возможность скачивания появится после покупки

IMDBOptimizer (OC 3) - Оптимизация базы данных

Найти версию для OpenCart 1.5 можно тут:

http://shop.opencart-russia.ru/imdboptimizer15

Найти версию для OpenCart 2.0-2.2 можно тут:

http://shop.opencart-russia.ru/imdboptimizer

Найти версию для OpenCart 2.3 можно тут:

https://shop.opencart-russia.ru/imdboptimizer23

Оптимизация базы данных интернет-магазина — это весьма непростой вопрос, порой требующий отдельных исследований.

И самое неприятное в этом процессе заключается в том, что сделать хоть какую-то оптимизацию может только тот, кто знает sql-запросы и разбирается в базах данных (БД).

Вот как раз для того, чтобы клиентам не приходилось заниматься тем, что им не обязательно знать, и создан IMDBOptimizer (OC 3).

Статьи про модуль или просто полезные материалы

1. Что такое индексы базы данных (для начинающих)?

2. Индексы и немного хитрой математики

3. Тестируем IMDBOptimizer для 2000 и 5500 товаров (индексы)

4. Тестируем IMDBOptimizer для 5500 товаров — Кэш SQL-запросов

Демо модуля

Демо админки (demo/demo)

Кэширование SQL-запросов

OpenCart, как и любая CMS, осуществляет немалое количество sql-запросов к БД, часть из которых являются однотипными (то есть для разных пользователей будет один и тот же результат).

И если товаров много, то sql-запросы легко могут стать основной причиной тормозов интернет-магазина (если у вас 5000+ товаров, то об этом вы, вероятно, хорошо знаете).

Однако, этого можно избежать за счет кэширования sql-запросов модулем IMDBOptimizer.

Возможности:

1. Гибридная система кэширования SQL-запросов (БД + файлы), позволяющая увеличить скорость генерации HTML-страницы и частично сбалансировать нагрузку между диском и БД. 2. Поддерживается фильтр «по словам» для исключения SQL-запросов из процесса кэширования (регистронезависимо). 3. Поддерживается фильтр «по URL» для исключения отдельных страниц из процесса кэширования SQL-запросов (регистронезависимо). 4. Так как кэшируются только SQL-запросы, то такой модуль можно успешно применять совместно с другими модулями кэширования (например, v2pagecache). Однако, совместимость лучше проверять на тестовом сервере. 5. Установили модуль? Ничего не нужно настраивать для кэширования. SQL-запросы автоматически начинают кэшироваться (с учетом фильтров), без необходимости что-то еще настраивать. 6. Еще одной отличительной особенностью кэширования именно SQL-запросов является то, что если один и тот же запрос используется при генерации разных веб-страниц или же просто выполняется повторно, то используется всего один кэш. Простой пример, открыли один и тот же товар из разных категорий — опции будут закэшированы всего 1 раз. 7. Можно применять как с созданием индексов, так и без. 8. При установке, модуль сразу создает типовую настройку, нужно лишь включить кэш. 9. Легко включается и легко отключается.

Ограничения и нюансы:

1. Так как это модуль кэширования уровня БД, то необходимо учитывать, что такие возможности, как отображение реального остатка товара или текущей цены в карточке, не поддерживаются (данные же кэшированы). 2. Кэшируются только SQL-запросы, начинающиеся с select. 3. Заменяется ядровой файл registry.php 4. Кэширование применяется только к клиентской части, в админской части все запросы выполняются как обычно. 5. Учитывайте, что кэширование это дополнительная нагрузка. Например, при первом открытии страницы товара, она может дольше загружаться (создается кэш).

Кэширование SQL-запросов — включение и очистка

Как включить кэширование:

1. Перейдите во вкладку «Кэш SQL-запросов». 2. Укажите, что кэширование «Включено» и сохраните настройки. 3. Кэш включен Для отключения нужно сделать все то же самое, только в шаге 2 установить «Отключено»

Как очистить кэш:

1. Перейдите во вкладку «Кэш SQL-запросов» 2. Нажмите кнопку «Удалить кэш» 3. Дождитесь соответствующего сообщения

Кэширование SQL-запросов — фильтры

Фильтр запросов «по словам»:

В данном фильтре построчно указываются фразы, которых не должно быть в запросе (приводятся к нижнему регистру). По умолчанию, указан список таблиц/префиксов для стандартной конфигурации.

При фильтрации, символ «#» заменятся на префикс базы данных, что позволяет создавать собственные конфигурации, которые легко переносить в другие интернет-магазины.

Важно! Пробелы так же учитываются - сделано для того, чтобы можно было исключать отдельные таблицы. Например, строка «#order» без пробела после order исключает все таблицы, связанные с заказом. А с пробелом после исключает только oc_order (рекомендуется так же дублировать правило и указывать апостроф после order, так как SQL-запросы формируются по-разному).

Пустые строки игнорируются. Так же игнорируются пробелы вначале и в конце SQL-запроса.

Фильтр запросов «по URL»:

В данном фильтре построчно указываются комбинации «[тип поиска]: [часть URL адреса]» (или же просто «[часть URL адреса]») для отключения кэширования при генерации конкретных страниц (таких как корзина или же оформление заказа). Все комбинации приводятся к нижнему регистру (регистронезависимо).

1. [часть URL адреса] – это какая-то часть URL адреса, например, «#/cart/» или «=checkout/». 2. [тип поиска] – имеет три значения: «l» (сравнивать часть адреса сначала URL; учитываются параметры запроса), «i» (искать часть адреса внутри URL; учитываются параметры запроса), «r» (искать часть адреса справа; параметры запроса не учитываются).

При фильтрации, символ «#» заменятся на домен сайта, что позволяет создавать собственные конфигурации, которые легко переносить в другие интернет-магазины.

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

Так же учитывайте, что префиксы «http://» и «https://» обрезаются, и что если фрагмент «[тип поиска]:» не указан, то поиск происходит слева (чтобы можно было просто URL вставлять).

Примеры:

r: #/cart Подходит «site.ru/cart», «site.ru/cart?asd=1». Но, не подходит «site,ru/cartini»

i: =checkout/ Подходит «site.ru/index.php?route=checkout/checkout&1=2». Но, не подходит «site.ru/index.php?route=check/some».

Кэширование SQL-запросов — дополнительные настройки

Максимальный размер вставки в БД. Данный параметр указывает свыше какого размера данных, информацию необходимо кэшировать в файл. Максимальное значение 65000. Рекомендуется использовать в диапазоне 20000 — 30000.

Время жизни кэша (сек). Здесь указывается время в секундах, в течение которое будет актуален созданный кэш.

Для тех, кому нужна только базовая оптимизация

Если вы не планируете сами вносить дополнительные индексы (или же оставите это тем, кто в этом разбирается), то, как уже говорил, модуль содержит настройки по умолчанию для базовой оптимизации БД.

Важно! Учтите, что операция весьма длительная и что требуется минимальная нагрузка в базе данных (то есть, желательно, чтобы пользователей сайта вообще не было или их было немного). В крайнем случае, вы можете создавать индексы по одной таблице отдельно, а не все скопом.

1. Сделайте бэкап всей базы данных! Это важно! 2. Откройте модуль 3. Выберите все таблицы (можно щелкнуть по ссылке «Выделить всё») 4. Чуть ниже, щелкните по кнопке «Генерировать!» 5. Откиньтесь на спинку кресла и наблюдайте как модуль создает индексы

Несколько щелчков мыши и у вас проведена базовая оптимизация базы данных!

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

Профилактика — оптимизация таблиц

Базы данных это сложные механизмы, где часть вещей остается на ответственность пользователей. Одной из них является снижение производительности, в связи с частым изменением и модификацией набора записей таблиц.

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

Поэтому для повышения производительности БД рекомендуется периодически выполнять оптимизацию таблиц. В среднем, для OpenCart это, примерно, раз в неделю.

Чтобы провести оптимизацию, достаточно лишь открыть вкладку «Сервис», выбрать таблицы и нажать кнопку «Оптимизировать!».

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

Починка таблиц

Как же неприятно открыть страницу товара и увидеть вместо карточки сообщение вида «PHP … Table is currupted … try to repair it...».

Редко, но такое бывает, что таблицы в БД MySql повреждаются. К счастью, чаще всего для их починки достаточно лишь запустить специальный запрос. Однако, чтобы это сделать необходимо зайти в хостинг, открыть панель phpMyAdmin, найти в интернете как составлять запрос и запустить его (а до этого всего, еще понять что делать с этой ошибкой). Для обычных пользователей или тех, кто только начинает, это весьма непростая задача.

Модуль же позволяет существенно упростить этот процесс. Нужно лишь указать поврежденную таблицу и нажать кнопку «Починить!» во вкладке «Сервис».

Учтите, что ошибки при подсчете не всегда означают ошибки восстановления. Так, например, таблица oc_cart попросту не поддерживает данный вид команды.

Блок с именами
Для настройки автоматического поиска и создания одиночных индексов, рядом с блоком таблиц есть три поля, где можно указывать конкретные имена полей, их начало или окончание (через запятую).
Стоит понимать, что они действуют по правилу ИЛИ. То есть если поле таблицы указано среди конкретных полей ИЛИ начинается с одного из указанных префиксов ИЛИ заканчивается на одном из указанных окончаний, то для поля в текущей таблице будет создан индекс.
Например:
Конкретные поля: product_id, language_id
Префиксы: stat, col
Окончания: _id
При таких настройках, индекс для поля &laq
shop.opencart-russia.ru

Оптимизация базы данных OpenCart (ОпенКарт) и ocStore

Совместимость

OpenCart 2.0, OpenCart 2.1, OpenCart 2.2, OCStore 2.1

IMDBOptimizer - Оптимизация базы данных

Версию для OpenCart 1.5 можно найти тут:https://liveopencart.ru/opencart-moduli-shablony/moduli/prochee/imdboptimizer-oc-1-5-optimizatsiya-bazyi-dannyih

Версию для OpenCart 2.3 можно найти тут:https://liveopencart.ru/opencart-moduli-shablony/moduli/prochee/imdboptimizer-oc-2-3-optimizatsiya-bazyi-dannyih

Версию для OpenCart 3 можно найти тут:https://liveopencart.ru/opencart-moduli-shablony/moduli/prochee/imdboptimizer-oc-3-optimizatsiya-bazyi-dannyih

Оптимизация базы данных интернет-магазина — это весьма непростой вопрос, порой требующий отдельных исследований. И самое неприятное в этом процессе заключается в том, что сделать хоть какую-то оптимизацию может только тот, кто знает sql-запросы и разбирается в базах данных (БД).

Вот как раз для того, чтобы клиентам не приходилось заниматься тем, что им не обязательно знать, и создан IMDBOptimizer.

Статьи про модули или просто полезные материалы:

1. Что такое индексы базы данных (для начинающих)? 2. Индексы и немного хитрой математики 3. Тестируем IMDBOptimizer для 2000 и 5500 товаров (индексы)4. Пример пользы индексов и IMDBOptimizer 5. Тестируем IMDBOptimizer для 5500 товаров — Кэш SQL-запросов

Демо модуля

Демо админки (demo/demo)

Кэширование SQL-запросов

Однако, этого можно избежать за счет кэширования sql-запросов модулем IMDBOptimizer.

Возможности: 1. Гибридная система кэширования SQL-запросов (БД + файлы), позволяющая увеличить скорость генерации HTML-страницы (тестировалось на стандартном OpenCart с 5500 товаров — прирост производительности от 30% до 70-80%) и частично сбалансировать нагрузку между диском и БД. 2. Поддерживается фильтр «по словам» для исключения SQL-запросов из процесса кэширования (регистронезависимо). 3. Поддерживается фильтр «по URL» для исключения отдельных страниц из процесса кэширования SQL-запросов (регистронезависимо). 4. Так как кэшируются только SQL-запросы, то такой модуль можно успешно применять совместно с другими модулями кэширования (например, v2pagecache). Однако, совместимость лучше проверять на тестовом сервере. 5. Установили модуль? Ничего не нужно настраивать для кэширования. SQL-запросы автоматически начинают кэшироваться (с учетом фильтров), без необходимости что-то еще настраивать. 6. Еще одной отличительной особенностью кэширования именно SQL-запросов является то, что если один и тот же запрос используется при генерации разных веб-страниц или же просто выполняется повторно, то используется всего один кэш. Простой пример, открыли один и тот же товар из разных категорий — опции будут закэшированы всего 1 раз. 7. Можно применять как с созданием индексов, так и без. 8. При установке, модуль сразу создает типовую настройку, нужно лишь включить кэш. 9. Легко включается и легко отключается.

Ограничения и нюансы: 1. Так как это модуль кэширования уровня БД, то необходимо учитывать, что такие возможности, как отображение реального остатка товара или текущей цены в карточке, не поддерживаются (данные же кэшированы). 2. Кэшируются только SQL-запросы, начинающиеся с select. 3. Заменяется ядровой файл registry.php 4. Кэширование применяется только к клиентской части, в админской части все запросы выполняются как обычно. 5. Учитывайте, что кэширование это дополнительная нагрузка. Например, при первом открытии страницы товара, она может дольше загружаться (создается кэш).

Кэширование SQL-запросов — включение и очистка

Как включить кэширование: 1. Перейдите во вкладку «Кэш SQL-запросов». 2. Укажите, что кэширование «Включено» и сохраните настройки. 3. Кэш включен Для отключения нужно сделать все то же самое, только в шаге 2 установить «Отключено»

Как очистить кэш: 1. Перейдите во вкладку «Кэш SQL-запросов» 2. Нажмите кнопку «Удалить кэш» 3. Дождитесь соответствующего сообщения

Кэширование SQL-запросов — фильтры

Фильтр запросов «по словам»: В данном фильтре построчно указываются фразы, которых не должно быть в запросе (приводятся к нижнему регистру). По умолчанию, указан список таблиц/префиксов для стандартной конфигурации.

Пустые строки игнорируются. Так же игнорируются пробелы вначале и в конце SQL-запроса.

Фильтр запросов «по URL»: В данном фильтре построчно указываются комбинации «[тип поиска]: [часть URL адреса]» (или же просто «[часть URL адреса]») для отключения кэширования при генерации конкретных страниц (таких как корзина или же оформление заказа). Все комбинации приводятся к нижнему регистру (регистронезависимо). 1. [часть URL адреса] – это какая-то часть URL адреса, например, «#/cart/» или «=checkout/». 2. [тип поиска] – имеет три значения: «l» (сравнивать часть адреса сначала URL; учитываются параметры запроса), «i» (искать часть адреса внутри URL; учитываются параметры запроса), «r» (искать часть адреса справа; параметры запроса не учитываются).

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

Примеры: r: #/cart Подходит «site.ru/cart», «site.ru/cart?asd=1». Но, не подходит «site,ru/cartini» i: =checkout/ Подходит «site.ru/index.php?route=checkout/checkout&1=2». Но, не подходит «site.ru/index.php?route=check/some».

Кэширование SQL-запросов — дополнительные настройки

Время жизни кэша (сек). Здесь указывается время в секундах, в течение которое будет актуален созданный кэш.

Для тех, кому нужна только базовая оптимизация

Несколько щелчков мыши и у вас проведена базовая оптимизация базы данных!

Профилактика — создание индексов

Для профилактики, необходимо запускать генерацию после установки любых других модулей, которые создают свои таблицы (не всегда в них имеются все необходимые индексы).

Индексы создаются самые простые без ограничений, так что в таблицах модулей не будет нарушена какая-либо логика (только если модуль не будет в последствии добавлять индексы без проверок, но обычно это редкость).

Профилактика — оптимизация таблиц

Починка таблиц

Блок с именами

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

Стоит понимать, что они действуют по правилу ИЛИ. То есть если поле таблицы указано среди конкретных полей ИЛИ начинается с одного из указанных префиксов ИЛИ заканчивается на одном из указанных окончаний, то для поля в текущей таблице будет создан индекс.

Например:

Конкретные поля: product_id, language_id

Префиксы: stat, col

Окончания: _id

При таких настройках, индекс для поля «product_option_value_id» будет создан (если его нет в таблице), так как поле заканчивается на «_id»

Карта индексов

В данном блоке можно составлять конкретные индексы, которые необходимо создать. Важно, что таблица каждого правила должна быть выбрана в списке таблиц. Иначе индекс не будет проверен или создан.

Правила составляются по следующему принципу:

Имя таблицы - Поле (, Поле)

Где имя таблицы может быть как указано с общим префиксом БД, так и вместо префикса можно использовать символ #, который будет автоматически заменен на префикс. Чтобы создать индексы из нескольких полей, их необходимо перечислить через запятую.

Например:

#product_description - language_id, product_id

В данном случае будет создан индекс (language_id, product_id) для таблицы oc_product_description (если такового индекса не было в таблице).

Удаление индексов

В закладке «Индексы» есть возможность удалять из таблиц индексы, созданные модулем. А именно те, которые имеют префикс «imdbo_».

Сделано это для того, чтобы исходные индексы или созданные вручную индексы не были случайным образом удалены из базы данных.

Подход к генерации имен индексов

Чтобы упростить использование созданных индексов для других авторов и создателей сайтов, в модуле был введен специальный алгоритм генерации имен создаваемых индексов.

Так что если вы будете планировать использовать данные индексы при построении своих sql-запросов (например, с возможностью повторного внедрения в другие интернет-магазины), то сделать это будет весьма просто.

Сам алгоритм подбора

Шаг 1. Составляется имя «imdbo_» + «[поле 1]» + «_[поле 2]» + … + «_[поле N]». Если у таблицы индекса с таким именем нет и его длина не превышает 64 символа (требование БД), то индексу присваивается это название. В противном случае, алгоритм переходит к следующему шагу.

Например, для индекса (product_id) будет использовано имя «imdbo_product_id», а для индекса (product_id, order_id) будет использовано имя «imdbo_product_id_order_id». И так далее.

Шаг 2. Составляется имя «imdbo_» + «[поле 1 — первые буквы слов в столбце]» + «_[поле 2 — первые буквы слов в столбце]» + ... Если индекса с таким именем нет и его длина не превышает 64 символа (требование БД), то индексу присваивается это название. В противном случае, переход к следующему шагу.

Например, для индекса (order_id, customer_id, store_id, payment_zone_id, currency_id, marketing_id), чья длина больше 64 символов в шаге 1, будет использовано имя «imdbo_oi_ci_si_pzi_ci_mi».

Шаг 3. Практически нереальная ситуация, но сделана для унификации. Составленное имя из шага 2 обрезается до 61 символа (если требуется) и к нему прибавляется приставка «_[номер]», где номер от 1 до 99.

Например, «imdbo_oi_ci_si_pzi_ci_mi_1», …, «imdbo_oi_ci_si_pzi_ci_mi_25», «imdbo_oi_ci_si_pzi_ci_mi_99». Если же и это недостижимо, то выполняется следующий шаг.

Шаг 4. Аналогично шагу 3, практически нереальная ситуация, но сделана для 100% унификации. Имя стоится как «imdbo_» + «[время UTC]» + «_[номер]». Например, «imdbo_1508711578_3».

А теперь, по-простому. При базовой оптимизации будут созданы индексы только шага 1. Шаг 2 это уже настройки из карты индексов (если вручную были указаны сложные составные индексы). Шаг 3 встретится очень редко, но если и встретится такое, то имена с постфиксами будут аналогичными от интернет-магазина к интернет-магазину. Шаг 4 сделан просто для безопасности, но в реальности невозможен (если, конечно, кто-то специально вручную не создал более 100 одинаковых индексов для таблицы).

Особенности и ограничения

1. Важно учитывать, что генерация индексов происходит для каждой таблицы отдельно. То есть для каждой таблицы отдельно посылается AJAX-запрос. Это связано с тем, что для больших таблиц создание одного индекса может быть весьма длительной операцией. Поэтому, если вы запустили генерацию, то просто дождитесь, когда рядом с кнопками появится сообщение, что генерация завершена. 2. Создаются только обычные индексы. 3. Удаляются только индексы, созданные модулем. А именно те, которые имеют префикс «imdbo_». Сделано для того, чтобы не сломать исходные настройки базы данных и вручную созданные индексы. 4. Если не существует указанных таблиц или полей, то указанные данные будут просто игнорироваться. 5. В БД проверяются только те таблицы, которые начинаются с префикса копии опенкарта (Сделано для тех, кто использует в одной БД несколько сайтов) 6. Пользователь должен иметь полные права для получения доступа к БД (или достаточные для получения метаданных и создания индексов) 7. Оптимизация производится для БД MySQL 8. Имена создаваемых индексов имеют технические названия (техническое ограничение автоматизации) 9. Если существует идентичный по полям индекс, то ничего не будет происходить. 10. Заменяется ядровой файл registry.php 11. Требуется boostrap и jquery

Установка, следующие версии и использование

1. Распакуйте в корень сайта содержимое (каталоги admin и system) 2. Откройте админку и установите модуль (если это следующая версия, то переустановите) 3. Обновите модификаторы 4. Откройте в админке модуль (редактирование)

Лицензия и использование

Сделано для версий OpenCart 2.0.3.1, 2.1.0.1, 2.1.0.2 и 2.2.0.0, ocStore 2.1.0.1, 2.1.0.1.1, 2.1.0.2, 2.1.0.2.1 Лицензия распространяется только для одного сайта. Т.е. 1 домен = 1 оплата. Купив модуль вы автоматически соглашаетесь с текстом лицензии. Модуль имеет принцип распространения "as is" ("Как есть"). Ввод лицензионного ключа необходимо осуществить в течение 5 дней после установки модуля. Лицензионный ключ состоит из двух частей. Ключи необходимо вводить так, как они были присланы, без лишних пробелов и символов. Запрещается несанкционированное использование, копирование, перепродажа, передача модуля третьим лицам, а также иные способы распространения, в том числе в ознакомительных целях.

Если вы приобрели модуль до введения лицензирования, то вам необходимо написать мне и указать при этом доменное имя сайта и тестовый домен, если таковой имеется (учтите, что тестовый домен должен быть тестовым, то есть поддоменом какого-либо сайта). Если у вас русский домен, то необходимо указывать то имя, которое указано в config.php в корне сайта.

Версия 1.3.0 - Совместимость с модулями Версия 1.2.0 - Добавлен кэш SQL-запросов Версия 1.1.0 - Изменен подход к генерации имен индексов - Добавлена возможность удалить созданные модулем индексы - Добавлена вкладка "Сервис" Версия 1.0.0 - Сам модуль

liveopencart.ru

IMDBOptimizer (OC 2.3) - Оптимизация базы данных

Название файла	Имя файла	Дата	Действие
IMDBOptimizer(2.3)_1.2.0.zip	opencart_file_8496.zip	2018-01-25 13:01:01	Платный файл
IMDBOptimizer(2.3)_1.3.0.zip	opencart_file_12213.zip	2018-04-09 03:04:59	Платный файл

* Возможность скачивания появится после покупки

IMDBOptimizer (OC 2.3) - Оптимизация базы данных

Найти версию для OpenCart 1.5 можно тут:

http://shop.opencart-russia.ru/imdboptimizer15

Найти версию для OpenCart 2.0-2.2 можно тут:

http://shop.opencart-russia.ru/imdboptimizer

Найти версию для OpenCart 3 можно тут:

https://shop.opencart-russia.ru/imdboptimizer3

Вот как раз для того, чтобы клиентам не приходилось заниматься тем, что им не обязательно знать, и создан IMDBOptimizer (OC 2.3).

Статьи про модуль или просто полезные материалы

1. Что такое индексы базы данных (для начинающих)?

2. Индексы и немного хитрой математики

3. Тестируем IMDBOptimizer для 2000 и 5500 товаров (индексы)

4. Тестируем IMDBOptimizer для 5500 товаров — Кэш SQL-запросов

Демо модуля

Демо админки (demo/demo)

Кэширование SQL-запросов

Однако, этого можно избежать за счет кэширования sql-запросов модулем IMDBOptimizer.

Возможности:

1. Гибридная система кэширования SQL-запросов (БД + файлы), позволяющая увеличить скорость генерации HTML-страницы (тестировалось на стандартном OpenCart с 5500 товаров — прирост производительности от 30% до 70-80%) и частично сбалансировать нагрузку между диском и БД. 2. Поддерживается фильтр «по словам» для исключения SQL-запросов из процесса кэширования (регистронезависимо). 3. Поддерживается фильтр «по URL» для исключения отдельных страниц из процесса кэширования SQL-запросов (регистронезависимо). 4. Так как кэшируются только SQL-запросы, то такой модуль можно успешно применять совместно с другими модулями кэширования (например, v2pagecache). Однако, совместимость лучше проверять на тестовом сервере. 5. Установили модуль? Ничего не нужно настраивать для кэширования. SQL-запросы автоматически начинают кэшироваться (с учетом фильтров), без необходимости что-то еще настраивать. 6. Еще одной отличительной особенностью кэширования именно SQL-запросов является то, что если один и тот же запрос используется при генерации разных веб-страниц или же просто выполняется повторно, то используется всего один кэш. Простой пример, открыли один и тот же товар из разных категорий — опции будут закэшированы всего 1 раз. 7. Можно применять как с созданием индексов, так и без. 8. При установке, модуль сразу создает типовую настройку, нужно лишь включить кэш. 9. Легко включается и легко отключается.

Ограничения и нюансы:

Кэширование SQL-запросов — включение и очистка

Как включить кэширование:

Как очистить кэш:

Кэширование SQL-запросов — фильтры

Фильтр запросов «по словам»:

Пустые строки игнорируются. Так же игнорируются пробелы вначале и в конце SQL-запроса.

Фильтр запросов «по URL»:

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

Примеры:

r: #/cart Подходит «site.ru/cart», «site.ru/cart?asd=1». Но, не подходит «site,ru/cartini»

i: =checkout/ Подходит «site.ru/index.php?route=checkout/checkout&1=2». Но, не подходит «site.ru/index.php?route=check/some».

Кэширование SQL-запросов — дополнительные настройки

Время жизни кэша (сек). Здесь указывается время в секундах, в течение которое будет актуален созданный кэш.

Для тех, кому нужна только базовая оптимизация

Несколько щелчков мыши и у вас проведена базовая оптимизация базы данных!

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

Профилактика — оптимизация таблиц

Починка таблиц

Блок с именами
Для настройки автоматического поиска и создания одиночных индексов, рядом с блоком таблиц есть три поля, где можно указывать конкретные имена полей, их начало или окончание (через запятую).
Стоит понимать, что они действуют по правилу ИЛИ. То есть если поле таблицы указано среди конкретных полей ИЛИ начинается с од
shop.opencart-russia.ru

Оптимизация Opencart (OMG) | Истрункция как поднять бабла

Я знаю знаю. Я мало пишу полезняка. И вспоминаю про бложик в крайних случаях. Но я стараюсь как могу, те кто знают почему у меня нет времени — поймут, те кто не знают ну простите, дальше будет легче.

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

Вобщем у меня два проекта и оба каких то конченных.Первый — 220 к товаров, 50 к товаров в одной категории и очень сложный фильтр подбора по весу, размеру и толщине товара слайдерами. Это все через MegaFilter и на вялом сервере. Однозначно победить такой огород и заставить его грузиться на холодную меньше секунды не получиться, но уже я сделал >3 сек, а было 64.Как что и куда — я расскажу подробно отдельно.

А вот второй проект изначально был очень простым и няшным. 10к товаров, минимум фильтров, хороший сервер мой любимый XDS шаблон, хотя это не отменяет того что XDS картофельный пидр. Но все таки он меньше всех наворотил кривой хуйни в отличии от сереги ломика и 29 алексея. Так вот проект был понятный и простой.

Пока в него не запустили системного администратора…Я знаю на память работу всех кешеров для Opencart, от Nitro до буста и высера Мракимрака, хоть он мне и друг (йодированый мрак, звучит). Так вот там гавна было много, я его весь выубил, ниче не меняется, товар добавляю ниче не меняется, index.php удаляю — ниче не меняется. ЭТО ПОЛНЫЙ ПИЗДЕЦ ….

Магазин не реагировал ни на что.. Мне показалось что у меня глюки. Я проверил айпи сервера, проверил десять раз пути виртуал хоста, все сука правильно. А изменений нет. Отключил Opcache, изменений нет.

И тут меня смутило, вскользь упоминание «нам там сервер настраиваили». И когда я полез в конфиги NGINX, я если сказать что ахуел — это не сказать ничего.

Один из конфигов был вот такой:

# Off by default proxy_buffering off; proxy_max_temp_file_size 256k; if ($request_uri ~* "^.+\.xml$") { set $no_cache "1"; } if ($request_uri ~* "^/(admin|(.*)/ckeditor)") { set $no_cache "1"; } if ($args ~* (product_attach_file_id|ckeditor)) { set $no_cache "1"; } if ($no_cache = "1") { more_set_headers "Set-Cookie: _mcnc=1; Max-Age=2; Path=/"; more_set_headers "X-Microcachable: 0"; } if ($http_cookie ~* "_mcnc") { set $no_cache "1"; } proxy_cache_valid 200 5m; proxy_cache_valid 301 302 304 10m; proxy_cache_valid 404 502 503 1m; proxy_cache_key "$scheme|$host|$request_method|$request_uri|$cookie_user"; proxy_cache common; proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; proxy_cache_use_stale error timeout invalid_header updating; # Mark cached request more_set_headers "X-Cache-Status: $upstream_cache_status";

# Off by default

proxy_buffering off;

proxy_max_temp_file_size 256k;

if ($request_uri ~* "^.+\.xml$") {

set $no_cache "1";

}

if ($request_uri ~* "^/(admin|(.*)/ckeditor)") {

set $no_cache "1";

}

if ($args ~* (product_attach_file_id|ckeditor)) {

set $no_cache "1";

}

if ($no_cache = "1") {

more_set_headers "Set-Cookie: _mcnc=1; Max-Age=2; Path=/";

more_set_headers "X-Microcachable: 0";

}

if ($http_cookie ~* "_mcnc") {

set $no_cache "1";

}

proxy_cache_valid 200 5m;

proxy_cache_valid 301 302 304 10m;

proxy_cache_valid 404 502 503 1m;

proxy_cache_key "$scheme|$host|$request_method|$request_uri|$cookie_user";

proxy_cache common;

proxy_no_cache $no_cache;

proxy_cache_bypass $no_cache;

proxy_cache_use_stale error timeout invalid_header updating;

# Mark cached request

more_set_headers "X-Cache-Status: $upstream_cache_status";

Для тех кто не понимает. Любая страница, которую формировал движок, укладывалась в кеш nginx и больше не обрабатывалась движком. Вобщем корзину можно было не собирать, так как у вас была чужая корзина. Статичный блять интернет-магазин Карл.

Какой то пидар справился. Я сделяль насяльнике.. Все быстрий. Твой магазин бизнес пришёль! Клиенты ничего не могут оформить — зато бистло!

Вобщем 3 часа жесткого секса с конфигами, еще три часа на оптимизацию магазина и мы получили заветные 170мс загрузки главной страницы и радостный googlePageSpeedInsight и 400-500 для страниц категорий под радостные вопли заказчика «наконец-то».

По итогу, сказать что я ахуел — это ничего не сказать, больше я ахуел только когда кое-кто сглотнул у софорпа паши и чучхе.

И тут по какому то совпадению, какая то тупая хуйня пришла на динокс форум и начала нести хуергу про http2, php7, memcache и остальную злоебучую хуергу.

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

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

Хуйнаныр

(22)Очко

(1)

ocshop.info

Ускорение OpenCart просто и эффективно

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

Ускорьте OpenCart и увеличьте конверсию до 30%

Проведенные исследования показывают, что при ускорении сайта всего лишь на 100 миллисекунд уровень конверсии увеличивается на 5%. На десктопных устройствах - на 2,4%, а на мобильных устройствах – на 7,1%.

Ускорение на 1 секунду увеличивает конверсию на 20%.

Ускорение на 2 секунды увеличивает конверсию на 30%.

Улучшите позиции в ТОП-е за счет ускорения OpenCart

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

Если увеличить скорость загрузки OpenCart, это уменьшит вероятность отказа, посетители будут воспринимать работу с сайтом более позитивно, будут больше проводить на вашем сайте. Все это в целом будет восприниматься поисковыми системами крайне позитивно.

Оптимизация изображений - наиболее простой и эффективный способ ускорить OpenCart

За счет оптимизации изображений можно значительно уменьшить суммарный объем данных (в байтах), загружаемых на странице. К примеру, вместо 20 МБ суммарный размер страницы уменьшается до 2 МБ. Страница объемом 2 МБ загрузятся гораздо быстрее, чем прежняя версия страницы объемом 20 МБ. За счет этого и происходит ускорение загрузки OpenCart.

OptiPic.io - самым простой способ оптимизировать изображения в OpenCart

Наш сервис позволяет автоматизировать рутинную и трудоемкую задачу по сжатию и оптимизации изображений. Подключение к сайту займет буквально 2 минуты. И все работае тавтоматически - вам лишь нужно настроить один раз настройки сжатия.

Пожалуйста, подождите. Выполняется анализ сайта.

Скоро вы будете перенаправлены на страницу с результатами проверки.

optipic.io