Yoda

Во первых. Разницы в производительности между redis и memcache нету. Во вторых на небольших магазинах разницы меджу файловым кешем и кешем в памяти нету, при условии наличия быстрого диска. В третьих ни один модуль кеширования не решает вопросы с запросами getProduct и getTotalProduct, на новых страницах которые отгрызают иногда 70-80% загрузки. В четвертых. То что вы сунули все запросы в кеш бесполезное мероприятие, так как на нормально настроенном магазине те же самые запросы занимают десятитысячные доли секунды и на общих протечках и простоях никак и ни на что не влияют. В пятых. Если говорить о том как и что кешировать, то кешировать надо повторяющиеся куски модулей. А не все запросы. Есть у вас целиком меню вот возьмите его уже готовое на уровне контроллеа закешируйте, тогда будет толк, так как итерации по формированию ссылок, изображений и всего остального никто не отменял. А вот эти все показательные процессы типа. Я тут все закеширвоал и повторно все быстро - с таким же успехом можно сохранить все страницы как html и думать что получилось. Но при этом все динамические страницы все равн будут тупые.

С таким же успехом можно поставить любой кеш фронта и будет то же самое.

У меня есть 100 0000 00000 товаров, тоже не покажу. Детский сад какойты. Бла бла бла бла бла.... ни о чем. У нас вот такие результаты есть: 1.5м товаров в категории с фильтром по 500 параметрам. Только рук не хватает всем заниться. Ищем способоных помощников. Есть у вас что-то хотя бы рядом похожее ?

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

Позвольте поинтересоваться каких? Есть пару проектов 1м+ товаров возьметесь? Или вы просто языком чешете ?

Кешировать атомарные запросы - зло!

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

Ага, особенно в этом месте: Но это все равно дешевле реализовать чем обращаться к некоторым разработчикам с просбами допилов.

Не совсем так. В первую очередь гугл учитывает ttfb - время ответа сервера до первого байта контента. Чем быстрее ваш магазин тем лучше индексация, так как гугл выделяет больший краулинговый бюджет, соответсвенно чаще приходит и индексирует больше контента. Все бустоподобные кешеры - не могут изменить эту ситуацию, так как быстро они отдают только уже готовые контент из кеша. А все страницы магазина на холодную как были так и остались медленные. Что касается попугаем pagespeed - они влияют возможно незначительно на общую оценку вашего магазина и значительно с точки зрения оценки улучшения поведенческого фактора пользователей. И данный фактор, действительно имеет существенное значение на позиции в выдаче. Чем быстрее и проще пользователю взаимодействовать с магазином, тем лучше поведенческий фактор. Прямой зависимости в формате накрутили 85+ оценку для мобильных устройств и трафик пошел вверх - нету! Это я вам могу сказать однозначно, основнываясь на личных наблюдениях на нескольких десятках улучшенных проектов за последние пару месяцев.

Потому что в браузере прикешилось https://webmaster.yandex.ru/tools/server-response/?url=http%3A%2F%2Fprimadonnanail.com%2F&user-agent=robot&if-modified-since= Все в порядке у вас.

Я знаю как сделать на 1 700 000 товаров.

Поменяйте на apache либо на php-fpm если сами сможете настроить. Почта заработает. Если не сможете - стучите в личку.

Очень похоже на то что у вас виртуалхост работает в режиме CGI.

Чет нестыковка у владельца восьмого магазина, у которого 100к товаров, с вопросом где брать программиста. Может лучше уроки сделать ?

Хочу сказать, что на нашем боевом проекте, мы уже перевалили за полтора миллиона товаров и вертим 1,3 миллиона товаров в одной категории с 400+ вариантами фильтра и все это за 500-700 мс динамической генерации без каких либо недокешеров. И хочу сказать что это недешевое удовольствие. Так что я хочу сказать, что если к тому что вы хотите сказать, у вас есть бюджет, то реализовать любые задачи - не проблема. А если просто вы хотите сказать, ради того чтобы сказать, то лучше попробовать себя в шоу давай поженимся, там тоже все хотят что то сказать. Хочу сказать, что 30к - это детский лепет. И тормозить там особо нечему, если есть нормальное окружение и исключены бутылочные горлышки. Хочу сказать, что человек не имеет никакого отношения к этому проекту. Делался он три года назад. И на сегодня это не самый лучший пример производительной системы на Opencart, так как там отсутсвтует быстрый sphinx фильтр и нормальный релевантный поиск с автоисправлениями и качественным ранжированием.

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

Ну что друзья, скажите что лучше, кто чем пользовался? Почему? Мои аргументы за простые. Sphinx решает потому что: Легковесный (50 мб против 800). Понятный и гибкий. Имеет русскоязычные корни, соответсвенно местами лучше заточен под кирилицу. Не требует установки java на сервере. В свежих версиях умеет делать qsuggest Я трогал живого Аксенова. Мои аргументы против тоже простые: Нет enterprise поддержки Нет SAAS реализации как в AWS например, т.е. нельзя купить себе немножко сфинкса в один клик. Не все хорошо с саппортом и скоростью правки багов. Я знаю массу апологетов эластика со своими аргументами. А вы что скажете ?

Кешируются опкоды. А не все.. https://habr.com/ru/company/mailru/blog/310054/

Чушь!

Многие участники коммьюнити знают, что я занимаюсь нагруженными проектами и собаку съел на поиске узких бутылочных горлышек. И opencartforum в том числе работает благодаря моему участию, так что поводов усомниться в моих высказываниях, особо не должно ни у кого возникнуть! Почему именно проектами а не проблемами движка opencart, потому что в самом движке все понятно и просто, а в проектах бывает все очень весело. 90% тормозов магазинов связано с разработчиками и слабой экспертизой разработчиков и программистов. Почему то в определенных узких кругах считается моветоном обсуждать косяки друг друга,и не дай боже сказать, Вася, ты дурак, ты своротил полный бред! Мне всю жизнь было побоку на чье-то субъективное мнение, и истина мне дороже чем чье-то псевдопозитивное отношение, поэтому в этих "узких кружках" разработчиков регулярно бомбит в мою сторону, когда кого-то из них мы выводим на чистую воду, но как говорили в КВН нас "много". Просто приведу вам пример из последних двух инцидентов с которыми мне пришлось столкнуться: История первая. Магазин на 10 000 товаров, все от души заполнено, все атрибуты, опциии, описания, все хорошо. Стоит фильтр от госоподина @SooR, который в целом в свежих версиях в том числе и моими молитвами, достаточно быстро работает, но нет! 4 секунду генерация без сфомированных кешей на выделенном сервер с 16 ядрами и вагоном оперативной памяти. Начинаем разбираться. У проекта есть собственный программист, который его ведет, и который там накопал такого...... что никуда не натянешь. От опенкарта осталось только названия. На вопрос зачем - ответ. Ну мне так надо было. На вопрос дружище. А как же там все патчи безопасности, обновления функционала, стабильные версии дополнений, в ответ текст - ты ваще кто здесь, чтобы мне что-то расказывать. ок ок. дружище, мое дело маленькое, найти причину тормозов. Путем нехитрых манипуляций обнаруживаем очень смешной код: $q = "SELECT slide_value_min, slide_value_max, option_id FROM " . DB_PREFIX . "ocfilter_option_value_to_product WHERE option_id IN (" . implode(',', $slider_options_id) . ") AND slide_value_min > '0'"; $query = $this->db->query($q); if ($query->num_rows) { $slide_data = array(); foreach ($query->rows as $row) { $slide_data[$row['option_id']]['min'][] = $row['slide_value_min']; $slide_data[$row['option_id']]['max'][] = $row['slide_value_max']; } foreach ($query->rows as $row) { $options_data[$row['option_id']]['slide_value_min'] = preg_replace('!(0+?$)|(\.0+?$)!', '', min($slide_data[$row['option_id']]['min'])); $options_data[$row['option_id']]['slide_value_max'] = preg_replace('!(0+?$)|(\.0+?$)!', '', max(array_merge($slide_data[$row['option_id']]['max'], $slide_data[$row['option_id']]['min']))); } } Это полный фак фак мазафак, вместо того чтобы использовать всю реляционную мощь mysql, это существо, перебирает и мерджит и сравнивает вагон массивов. Конкретно в нашем случае у нас было 4000 значений из базы, на каждое из которых работало вот это preg_replace('!(0+?$)|(\.0+?$)!', '', max(array_merge($slide_data[$row['option_id']]['max'], $slide_data[$row['option_id']]['min']))); 4000 итерация регулярки + объединения массива + нахождение max значения. Это даже не индусский код - это ДНО... Сидит человек на зарплате, пилит проект, накрутил его так , что кроме него там никто не разберется, чтобы не дай бог его не уволили, и пишет ДНОООООООО!!!! Это не код, это 80 левел ДНА. Пятиклассники на информатике такого не делают. Ок, исправляем, немного костыльно, быстро, за красоту не платят, делаем так: $q = "SELECT MIN(slide_value_min) as slide_value_min, MAX(slide_value_min) as max_slide_value_min, MAX(slide_value_max) as slide_value_max, MIN(slide_value_max) as min_slide_value_max, option_id FROM " . DB_PREFIX . "ocfilter_option_value_to_product WHERE option_id IN (" . implode(',', $slider_options_id) . ") AND slide_value_min > '0' GROUP BY option_id"; $query = $this->db->query($q); if ($query->num_rows) { $slide_data = array(); foreach ($query->rows as $row) { $options_data[$row['option_id']]['slide_value_min'] = (int)$row['slide_value_min']; if($row['max_slide_value_min'] > $row['slide_value_max']) { $options_data[$row['option_id']]['slide_value_max'] = (int)$row['max_slide_value_min']; } else { $options_data[$row['option_id']]['slide_value_max'] = (int)$row['slide_value_max']; } } Просто одним запросом получаем и min и max и это не 4 секунды, а где-то 50-70 мс.. Все работает. В ответ слышим.. Ну ты решил затык с тормозами, спасибо. Дальше мы сами разеберемся. Увещевания о том, что дядя, там же патчи безопасности, обновления алгоритмов, верни все в базу.. Бесполезно!! Я еще и плохой оказался, так как намекнул владельцам, что вас дрючат и парень вас на себя завязал надолго и всеръез! Все таки надо совесть иметь и думать что, тебя собъет машина, а кто-то должен после тебя твой код починить. Вот это понимание отсутсвует у 99% напрочь. Второй кейс. Приходит человек с жалобами тупит поиск, ок ставим ему sphinx, и получаем все равно те же 4 секунды ответа... Идеально быстрый магазин. Главная страница без глобального кеша 130мс, страница категорий 300-400мс, поиск 4000. Медленных запросов - нет! Выборка из сфинкса - порядка 20-30мс. Но тупит.... Ок ок.. Начинаем копать и видим странное дно... SEO CMS PAGES ver.1.1 Отключаем... И вииииииииииииииууууу... 350 мс генерация страницы.. Я ни в коем случае не буду писать автору, и гооврить что у него там проблемы, ему писано переписано и про его дыры и про его ночной код. У него звезда во лбу и это бесполезно, Я просто удалю эту чушь! И мы получим ооооооооооооочень быстрый магазин. И эти люди еще лезут в оптимизацию и ускорению, делают какие-то модули для оптимизации, когда другие их наработки делают +4 секунды на голом месте. Серьезно? Морали никакой. - Просто если у вас тупит поиск - отключайте это дно а лушче вообще не пользоваться разработками этого автора. ЭТО МОЕ ЛИЧНОЕ МНЕНИЕ Но очень много частных случаев с модулями этого автора. А на площадке это все как продавалось так и продается. Уважаемая администрация, вам не стыдно, что у вас в каталоге дополнений продается откровенный шлак а вы закрываете на это глаза? Это же не первый не второй раз? Сколько можно класть на пользователей дополнений? Ваше мнение уважаемая администрация, может не совпадать с моим, но у меня есть пруфы, если вдруг у вас возникнут сомнения в правдивости моих тезисов!

Не знаю - так как надо по факту смотреть ваше окружение. Если там все по нулям, знач у вас некорректно сконфигурированно php окружение и надо разбираться.

На opcache влияют конфиги php, так как это технология, которая работает на уровне интерпретатора а не web-сервера. Если сильно свербит можете поставить вот это: https://github.com/amnuts/opcache-gui И увидеть вживую как оно есть.

Opcache - не касается напрямую Opencart, эта приблуда оптимизирует время выполнения скриптов php, а опенкарт у вас, битрикс, мажента, или php echo "hello world!";l Не принципиально. Т.е. opcache дает прирост выполнения ЛЮБЫХ скрпитов пхп, за счет кеширования опкодаов. И напрямую с движком он не можут быть связан никак!

Да можно и так, только кеш надо переделать в формате private $cache_data = []; __desctruct { public function set($key, $data) { $cache_data[$key] = $data; } foreach($cache_data as $item) { store($item......); } } Будет небольшой оверхед по памяти, но не будет фризов файловой системы в моменте $cache->set

некоторых типов object (см. примечание ниже). !!! Поэтому что? Не заморачиваемся!!!! А используем то, что умеет делать по человечески. Ну а фанаты спектрума и калькулятора мк52, могут в двоичном коде писать дальше морской бой.