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

Скачать / Купить дополнение OpenCart Lightning: кеширование, оптимизация, улучшение SEO и Google PageSpeed Промо! Мои бесплатные дополнения: Replacer: редактирование HTML и текстов магазина прямо на странице Тестовый сайт: копия вашего рабочего магазина в один клик OpenCart Lightning - это мод, который реально ускоряет магазины и дает ощутимый результат. Страницы открываются почти мгновенно, высокие баллы PageSpeed и минимальный TTFB дают отличный плюс к SEO. Работает со всеми версиями OpenCart и ocStore. Вот ссылка на демо-магазин с 20000 товаров на хостинге за $5 - https://demo.devs.mx/lightning А вот демо с JOURNAL3 - https://demo.devs.mx/journal3/ почти мгновенное открытие страниц оптимизировано для получения высоких показателей в новом Google PageSpeed Insights быстрая работа с большим количеством товаров и категорий повышение удобства навигации по магазину и рейтингов в поисковиках не надо настраивать и приглядывать, просто работает отпадает необходимость в дополнительных модах оптимизации или кеширования Если вы залогинены в админку - страницы, на которые вы заходите - после этого перегенерируются. То есть, если вы хотите увидеть изменения - просто обновите страницу. В большинстве случаев нет необходимости очищать кеш вручную - все обновляется автоматически. После установки у вас будет 7 дней тестового периода, дальше надо будет купить лицензию. Внимание: OpenCart Lightning не работает на localhost, только на реальных интернет-серверах. Установка Важно! Перед установкой Lightning отключите или удалите все расширения для кэширования и оптимизации – если они у вас установлены. Они могут привести к конфликтам и сделают общую скорость медленнее. Lightning ускоряет каждый аспект более эффективным способом, чем конкурирующие продукты. Сторонние расширения WebP не будут работать корректно с кешированием страниц, поэтому отключите их, если они у вас есть. Lightning включает свою поддержку WebP по умолчанию. Lightning приводит ссылки всех товаров к каноническому виду shop.ru/seo-url-tovara для того, чтобы у каждого товара была только одна URL для большей эффективности. Если по каким-либо причинам вам это не подходит, активируйте опцию Отключить унификацию ссылок на товары в дополнительных настройках Lightning. Загрузите lightning.ocmod.zip в инсталлятор, зайдите в Модификации и обновите их. Если сайт лег и админка не открывается - вот как быстро все вернуть назад. Если после установки Lightning витрина магазина не открывается или выдает ошибку, попробуйте активировать опцию Отключить оптимизацию шаблонов в дополнительных настройках Lightning. Обновление 1. Выключите Lightning. 2. Очистите кеш Lightning. 3. Зайдите в Модификации и удалите модификацию Lightning. 4. Установите новую версию Ligthning. 5. Обновите Модификации. 6. Включите Lightning. Добавил MaxD Добавлено 04.12.2014 Категория Кэширование, сжатие, ускорение Ioncube Loader Нет ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 OpenCart.Pro, ocShop Opencart.pro 2.3 Opencart.pro 2.1 OcShop 2.0.3.х Обращение к серверу разработчика Да  

Завантажити / Придбати розширення Буслік Кэш / Buslik Cache Lite ИНФОРМАЦИЯ Название модуля: Буслік Кэш - "Buslik Cache" Версия модуля: 1.0 Тип лицензии: Lite (Liteware, linkware, beerware, muffinware) - пробная версия (упрощённая) Тип установки: ocmod Язык: Беларуская мова, English, Русский язык, Українська мова Дата создания: 02.10.2019 Был протестирован на: OpenCart.pro 2.1.0.2.2 и 2.3.0.2.6, OpenCart-"Русская сборка" 2.1.0.2 (rs1), 2.3.0.2 (rs6) и 3.0.2.0 (rs3), ocStore 2.1.0.2.1 и 2.3.0.2.3 - шаблон (default) Название архива: Buslik Cache v1.0 Lite OpenCart 2.X-3.X.zip ПОЛНАЯ ВЕРСИЯ ЗДЕСЬ ОПИСАНИЕ Модуль предназначен для уменьшения нагрузки на вашу базу данных и сайта в целом тем, что создаёт файл готовой страницы и после каждый раз отдаёт её пользователю. Также поднимает оценку Google PageSpeed. Если у вас на сайте шаблоны от индусов, то скорее модуль вам не поможет, и нужно нанимать специалиста, или менять шаблон на эти, или покупать полную версию модуля. Этот модуль урезанная версия платного модуля. В платной версии возможно многое. ВНИМАНИЕ! Оригинальные файлы магазина не заменяет! УСЛОВИЯ СОГЛАШЕНИЯ - Beta и Lite версии устанавливаете на свой страх и риск - бэкап базы данных (далее - БД) обязателен; - Модуль (модификатор, дополнение, расширение, приложение) (далее - Модуль) можно устанавливать на неограниченное количество доменов; - Редактировать код запрещено; - Распространение модуля разрешено с сохранением ссылок автора и исходного кода; - Техническая поддержка (далее - ТП) не осуществляется; - Адаптация модуля под другую версию Опенкарта, нестандартный шаблон и сторонние модули - платная; - Автор не несёт ответственности за потерю или находку дохода пользователя из-за работы модуля; - Автор модуля оставляет за собой право в любое время внести изменение в настоящее условие, описание и исходный код модуля; Автор buslikdrev долучення 10.05.20 Категорія Кэширование, сжатие, ускорение Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 OpenCart.Pro, ocShop Opencart.pro 2.3 Opencart.pro 2.1 OcShop 2.0.3.х Звернення до сервера розробника Нет  

C разрешения владельца магазина, позволю себе, рассказать вам чудесную историю, про то какие бывают модулепейсатели, оптимизаторы, почему они кровососы, и что с ними делать, думаю, что растянем на несколько частей, потому что в рамках одного поста не вместится. Так исторически сложилось, что я дружу с владельцами и инженерами некоторых хостеров. Неделю назад, ко мне обратился ведущий инженер крупного белорусского хостера с вопросом, у нас тут у клиента перегруз по всем лимитам 600%, как ему помочь? Ответ был - никак. Просто при первом же осмотре, в магазине обнаружился filter biber и вот эти все его недосео посадочные страницы. Как говорят создатели сериала "настоящий детектив" по просьбе выживших мы не приводим домен магазина. Но когда проект перенесли на хороший VPS с 5 гигагерцовыми процессорами, магазин показывал вот такую нагрузку: После того, как ваш покорный слуга сделал волшебные магические пассы, у нас стало так: Мы снизили потребление процессорных ресурсов в десять раз. А потребление памяти в текущей конфигурации - величина постоянная, так как ее в основном жрет php-fpm и в режиме ondemand делает это не больше и не меньше. И самое главное. Ну у нас две самых главных вещи. Во первых мы пустили ботов не на псевдосеомусорстраницы, а на нормальный контент, и уменьшили экстремально время ответа сервера на холодную без кешей, джет кешей, а для простого обычного пользователя в три-четыре раза. Как это происходило, что мы сделали, почему фильтр бибер, джет кеши и лайтнинги - это дикое зло. В следующей серии. В дополнение, хочу заметить, между этими двумя графиками два дня и семь лет. Два дня мы это сделали. Семь лет, приходило понимание как это сделать!

Порадовался я тут значит этой истории Сделал промочку на вторую часть... И... Все опять накрылось медным тазом. На следующий день после того как магазин зажил полной грудью он опять начал тупить при чем жестко. И если фронт работал кое-как, то вот товары обновить возможности не было никакой. Но давайте с самого начала. С чем мы столкнулись. Магазин на 65 000 товаров, самая большая категория на 10к товаров, у каждого товара 5-8 атрибутов. Из бредомодулей стоит jetcache и filterviewer. Жил себе и жил этот магазин на обычном виртуальном хостинге, пока не начал потреблять порядка 30% физического сервера хостинга, превышая в пике допустимый лимит нагрузки пакета в 10 раз. Когда я первый раз увидел этот проект, у меня было однозначное мнение, что это мертвый проект, так как скорее всего какой-то сеошник посоветовал сделать вот эти все посадочные под все со всеми и глаз пал на FV. В чем печаль ситуации. Этот фильтр генерит явную ссылку на страницы фильтра в формате все со всеми атрибуты, опции, и еще вот это в наличии и по рейтингу. И вместо того чтобы сделать явными только посадочные, а остальные страницы спрятать за js-редирект, а еще бы и закрыть по какому то признаку в robots, как тот же ?mfp= в Мегафильтр, viewer такой возможности не дает. Так как это же сео, это посадочные, это сеошники так сказали. В итоге боты прриходят и застряют в этом болоте из сотен тысяч мусорных страницы фильтра, вместо того чтобы приходить на нормальные страницы товаров, категорий и руками созданные размеченные посадочные с адекватными тайтлами и контентом. Ща прибегут хейторы и скажут йода опять несет чушь. Предлагаю любому хейтеру показать мне проект, где подобный финт ушами от вивер фильтра дали хотя бы +200 уников из органического поиска. И еще, viver говорит, что ну че там - ну у меня ж ноиндекс на второй третий уровень вложенности. Это все прекрасно и волшебно, но для того чтобы увидеть этот ноиндекс все равно надо сгенерить страницу, а их я напомню несколько сот тысяч. На которые пришли гугл, яндекс и бинг бот. Как говорит один мой знакомый, тут никакого сервера как у Пентагона не хватит. Ну и поверху всей этой красоты еще стоит jetcache, который создает видимость спокойствия. Не ну а че.. Ну из файлика же быстро html подгрузился по готовому кешу. А то что 3+ секунды загрузка на холодную. Так ну то фигня - самое главное же из кеша быстро, все 5 страниц которые туда попали и еще 50 000 страниц фильтра, а нормальный контент как был туп так и остался. Как грузилась категория на 10 000 товаров 5-6 секунд так и грузится (там еще нон стоп обновления товаров) и весь jetcache ходит по бороде так сказать. Но вот ложное чувство нормализации процесса давал. Ок. что делать? Перенесли сайт на впс - стало хуже. Так как на шареде, можно было забираться по уши в ресурсы соседей, а тут два ядра - и только они. И в этот момент владелец магазина обратился ко мне с вопросом, что же таки куда. И самое удивительное, он признал с первого раза всю дичь логики работы фильтер вивер и согласился его убрать. И поменять на OcFiltere от @SooR. После настройки серванта, после простановки индексов в базу, решения вопроса с кешами, выжигания filterviever и jetcache - у нас вроде нормализовалась работа. И получились вот те графики которые были в первой статье. Но это была только прелюдия.... Вчера опять проект лег в момент попытки обновить какие-то 6000 товаров. Начали разбираться и обнаружили падение базы. Начали смотреть почему падает, обнаружили нехватку памяти. Начали смотреть куда девается память - обнаружили оверхед потребления php-fpm. Начали разбираться почему - обнаружили, что в момент импорта-обновления таблиц mysql хоть их и не блочит, потому что innodb, но начинает подтупливать, потому что перестраивает индексы на больших таблицах. И в момент тупняка базы, становиться очередь запросов на генерацию страниц из php-fpm потоков, которые резервируют под себя память и в какой-то момент watchdog прибивает базу, как самый жадный процесс по потреблению памяти и пытается ее перезапустить, естественно убивая импорт и создавая проблемы для пользователей. Ну и оно в целом все время висит в момент импорта. Начали смотреть внимательней, и обнаружили в логах очень много зверей типа ahrefs, mj12 и других. Закрыли. Не полегчало. Попросил я дообавить 2 гигабайта памяти к 2 существующим на сервер. Добавили полегчало. И мало того, еще перенесли VPS на сервер с физической частотой процессоров в 5Ghz и вот тут полегчало глобально, импорт пролетел за какие-то 70 секунд. Все отлично. Прошли сутки. И сегодня опять мне прислали вот такой скрин: Со словами - там в логах очень много гугл бота. Я был готов уже проклять тот день когда я сел за баранку этого паровоза. Но нет. Все решили. И сейчас вот так И время ответа страниц без каких либо кешей 300-800 мс. С фильтрами, и всем остальным всем, что было до. Вы спросите, а что же ты йода втираешь дичь. Типа. вот ты там решил потом не решил, потом опять справил и опять нет. Ну вот такой вот я Йода, который не может предусмотреть все. Но если вы не хейтор, а вам интересно что же это было и как исправилось. То я вам расскажу, и это очень смешно: Помните мы убрали фильтр? А помните, по страницам фильтра боты ходили? А теперь они увидели там 404, и что? Да пошли с утроенной силой чтобы проверить весь ресурс. На всю эту прорву мусороного контента, который был в очереди на сканирование. И был уже проиндексирован! Просто всего ничего к нам зашло за день и только на html контент (обращения к статике в логе не учитываются): Удивительно, чо же там с нагрузкой. Ну ладно. Но у нас же проблема. Боты приходят на чпу ссылки. У нас нет хвоста site.com/filterviewer/какаятотупаястраницафильтра. Так бы мы могли спокойно в nginx-конфиге заблочить сразу это все в 404 на корню и забыть про проблему. Ок. Смотрим, что у нас есть в ссылках, а у нас там есть ~ в ссылках вида 023~500-031621~sp0720-8003-ts~500-0702701~500-0702702~2140-180~2141-228~2516-240~4152-250~4155-213~kr2300-205~tstr6-762ef~500-031616. Проверяем таблицу url_alias, там у нас символа ~ нету. Волшебно, БИНГО. Через минуту после блокировки всех ссылок с таким признаком на уровне web-сервера, наша нагрузка пришла в норму и проект зажил ровно так как и должен работать, зарабатывая владельцу деньги а не геморрой и седые волосы. Нам еще много предстоит сделать, чтобы гадкий утенок превратился в красивого лебедя. Но эта моя сказочка про конкретную историю, как бывает когда два неграмотных дополнения могут привести к остановке бизнеса на пару недель, и про то что не всегда стоит бежать покупать стопятидесятиядерные сервера, так как не разобравшись в корне проблем, решить вопрос железом может быть или слишком дорого или невозможно в принципе. UPD: прошли сутки и у нас новое бинго 657 мать его тысяч запросов от гугл бота.. Как это развидеть! Viiver ты что курил, прежде чем написать этот бред? Как тебя выпустили, я не знаю откуда, но людям тебя нельзя показывать!

Есть на форуме неплохое дополнение Красиво, информативно, кошерно. Если у вас 3 товара, все ок! Но, если у вас их 5000 и на каждый 5 изображений, вот эта штука, чтобы подсчитать размер файлов, сканирует всю структуру папок кеша изображений. Зачем и для чего? Ниче не имею против автора, и скорее всего он просто про это не думал и не сталкивался, но стоит сделать каким то образом эти данны обновляемыми раз в 15 минут и хранить их где-то и кнопку принудительного пересчета. Ну и вроде - не страшно, что админка тупит - но, если вы подгружаете так постоянно файловую систему - то может тупить и фронт! Так что если вы ощущаете тормоза админки и у вас установлен этот модуль - подумайте, стоит ли оно того!

8 Скачать / Купить дополнение Старая версия удалена автором This module is removed by the author Добавил sitecreator Добавлено 06.05.2018 Категория Прочее Системные требования Метод активации Без активации Ioncube Loader Нет ocStore Несовместим OpenCart.Pro, ocShop Несовместим Обращение к серверу разработчика Нет  

Всем привет! Изучив всю информацию, которую смог найти на форуме, задаю вопрос в собственном топике: Дано: Сайт http://naocar.ru/ Чистый ocStore 1.5.5.1.2 cо всеми отключенными модулями (категории, карусель, рекомендуемые, фильтр, хиты, акции), с отключенным "количество товаров в подкатегории". Из модулей установлен только "комплекты товаров", работает корректно, влиять не должен. На сайте добавлено порядка 5000 категорий, товаров почти нет - пара десятков (будет не более 500). Десять родительских категорий закреплены на главной; все остальные - это их подкатегории. Проблема: При переходе в любую из родительских категорий, страница грузится до семи секунд. В самые большие категории дольше всего (Volksvagen, Toyota). При заходе на главную страницу сайта, в подкатегории и в другие разделы лагов нет. Причина проблемы: Количество запросов на главной - всего 31. Для примера, в категории Volkswagen - аж 616: totalProcessTime - 7.2354209423065 sec Queries - 616. Queries time - 7.1887283325195. Все остальные 600 запросов имеют такой же вид, как 8,9,10: Подскажите, какими путями можно уменьшить время загрузки страниц? Надеюсь, что эти запросы нужны только втростепенным функциям, вроде пагиатора, чтобы вычислять последнюю страницу, или поиску категорий. Если это так, то буду очень благодарен, если подскажете, как их отключить, или тыкнете на топик, где этот вопрос уже решили. Сам пока ничего не трогал, сделал только индексацию (мой уровень программирования - копипейст). Если не отключить, то как еще бороться? Спасибо!