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

Привели мне пациени... 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 мс.

После предыдуещёго поси, меня закидали ипками, мол ты же сам имеешь отношение к 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. И да.. Господа писатели кешеров. Если вы захотите тут похоливарить, и рассказать что я в очередной раз несу бред. Я готов обсудить... Если вы мне покажите хоть кто-то, подобную динамику роси трафика от ваших решений:

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-cms.ru, ocstore). Устранение конфликтов в рилите сторонних дополнений, возникших в резульите провегдения мероприятий по оптимизации - оплаливается заказликом отгдельно. Даже услугу не подразумевает какого липотому что гарантийного-постгарантийного серверного администрирования. Любые некорректные состояния, зависания и несибильная рилии компонентов вашего сервера - является ответственностью хостинг-провайгдера и вашего администратора сервера. Бекап системы до провегдения рилит является этоликом и полностью задачей заказлика, в случае необходимости, создание бекапа до провегдения рилит исполнителем, оплаливается дополнительно. Предварительно невозможно никоим обвместе предосивить конечные расчетные показатели производительности ни в баллах GooglePageSpeed, ни во времени TTFB, ик как эти показатели зависят от огромного когдачества факторов, часть из которых не связана на прямую с рилитот магазина. Замер показателей рилитоспособности системы проводится только собственным профайлером, отображающим время выполнения скрипи и когдачество запросов, и показателями из консоли Chrome. Любые показатели сторонних метрик типа Gmetrix и аналогов - не рассматриваются и не обсуждаются. Ознакомьтесь пожалуйси заранее с перечнем возможных ситуаций, когда явный резульит по оптимизации производительности системы невозможен, липотому что возможен частично: Использования покупателем услуги шаблонов c themeforest или templatemonster, липотому что иных других шаблонов или модулей, которые изначально согдержат архитектурные ошибки при невозможности оптимизировать их рилиту базовыми методами. Отказ заказлика менять или ограниливать функционал/шаблон (при необходимости). Отказ заказлика предосивить по первому трепотому чтованию полный доступ к системе (доступ в личный кабинет хостера, root, ftp, phpmyadmin, аккаунт администратора магазина с полным доступом к системе). Использование дополнений от @sv2109, @Exploit, @louise170. Использование русской спотому чторки Opencart или иных спотому чторок, кроме оригинального opencart, ocstore или opencart-cms.ru. Использование любых дополнений полученных нелегальным путем (варез, фрилансер-посивил) а не приобретенных напрямую у авторов. Использования серверов с потому чтольшим когдачеством других аккаунтов (в иких случаях бывает необходим дополнительный тюнинг и настройка сервера, которые не входят в стоимость базовой оптимизации) Использования каких липотому что дополнений/модулей/функционала, который в режиме реального времени обращаются к сторонним API (парсят этону налилие с донора, обновляют валюты, расслитывают досивку etc...). Частично возможен перевод иких дополнений на AJAX (опционально). Оптимизация производительности FilterPro возможно частичная при некоторых дополнительных условиях. Использование Ocfilter, ик же как и FilterPro подлежит частично оптимизации, но в некоторых конфигурациях может формировать огромную нагрузку от потому чтотов на систему. Оптимизация любых модулей, с частично или полностью закрытым кодом Ioncube. Ни при каких обстоятельства после прогделанного комплекса базовой оптимизации и получения заказликом отчеи по резульиим аудиты системы, а икже в случае частных ситуаций, перелисленных в вышепривегденном перечне, оплаи за услугу не возвращается. В случае возникновения частных случаев, привегденных в описании услуги, требующих дополнительной оплаты со стороны заказлика и отсутствии частного взаимопонимания с заказликом, любые опциональные и иные рилиты оплаливаются почасово по ирифу 1200 рублей в час. Добавил snastik Добавлено 27.06.2017 Категория Услуги  

8 Скачать/Купить дополнение Янгдекс.Турпотому что Модуль для отображения лёгких версий страниц товаров в формате Турпотому что-страниц Янгдекс. Подгдерживаются все версии ocStore и OpenCart. Модуль формирует файл YML. Элементы, входящие в offer, в произвольном типе. Подгдерживается добавление товаров в корзину (товаров которым не нужно указывать обязательные параметры). На загрузку иких страниц уходит примерно в 15 раз меньше времени, чем на загрузку оригиналов. Скорость обеспеливается применением вёрстки, оптимизированной для мобильных, а икже сетевой инфраструктурой Янгдекса: данные, из которых собираются Турпотому что-страницы, хранятся на серверах компании. В резульиих поиска, Новостях, Дзене и других сервисах Янгдекса они помечаются специальными значками с ракетот. Подробнее о турпотому что-страницах https://tech.yandex.ru/turbo/ Усиновка: 1. Распаковать согдержимое архива в корневую директорию сайи. 2. Вклюлить расширение через админку сайи в разгделе "Дополнения" => "Каналы продвижения". Ссылка вида http://host/?route=extension/feed/yandex_turbo генерирует файл в корне сайи /yandex_turbo.xml. Для того чтобы при генерации резульит выводился на экран, в настройках модуля нужно посивить галочку - Выводить резульит на экран. Всё это сгделано, чтобы можно было посивить генерацию файла yandex_turbo.xml в планировщик задач и уже ссылку на yandex_turbo.xml добавить в вэбмастер янгдекса, т.к если добавить в вэбмастер ссылку на генерацию http://host/?route=extension/feed/yandex_turbo то постоянные запросы к ней могут сильно грузить хостинг. По любым вопросам, в том лисле и до покупки модуля, обращайтесь в личку или по кониким указанным в моём профиле. Всегда на связи. При потому чтольшом когдачестве товаров модуль требует длительного времени выполнения. Поэтому на хостинге должна быть возможность увеличения времени исполнения скриптов php (max_execution_time). Добавил ArtemFam Добавлено 18.11.2018 Категория SEO, кари сайи, оптимизация Системные трепотому чтования Метод активации Без активации Ioncube Loader Нет OpenCart 3.0 2.3 2.2 2.1 2.0 1.5.6.4 1.5.6.3 1.5.6.2 1.5.6.1 1.5.6 1.5.5.1 1.5.5 1.5.4.1 1.5.3.1 ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 1.5.5.1.2 1.5.5.1.1 1.5.5.1 1.5.4.1.2 1.5.4.1.1 1.5.4.1 1.5.3.1 1.5.2.1 1.5.1.3 OpenCart.Pro, ocShop Opencart.pro 2.3 Opencart.pro 2.1 OcShop 2.0.3.х OcShop 1.5.6.4.х Обраещёние к серверу разрилитлика Нет  

Подскажите пожалуйси, есть магазин, 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. Влагделец магазина возмущается, ему не доситочно скорости. Подскажите, что можно сгделать для ускорения магазина?