Yoda

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

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

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

Не совсем так. В первую очередь гугл учитывает 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, могут в двоичном коде писать дальше морской бой.

https://medium.com/@moinuddinchowdhury/serialize-vs-json-67fe872a7755 Это что касается скорости. ну и <?php $json = '{"a":1,"b":2,"c":3,"d":4,"e":5}'; var_dump(json_decode($json)); var_dump(json_decode($json, true)); ?> Результат выполнения данного примера: object(stdClass)#1 (5) { ["a"] => int(1) ["b"] => int(2) ["c"] => int(3) ["d"] => int(4) ["e"] => int(5) } array(5) { ["a"] => int(1) ["b"] => int(2) ["c"] => int(3) ["d"] => int(4) ["e"] => int(5) } А serialize умеет только массивы. И что касается темы в целом. Попытка вот здесь сэкономить - это экономия на спичках. От того что на 100к товаров разбирается кеш сеопро. будет он 200 или 220 мс парсится в объект - ничего не поменяется, а особенно если ссылки с полным путем категорий, где cache->set cache->set cache->set и так 150 раз. Но в тоже время на 1000 товаров юзать готовый массив имеет место быть на 300%.

Обнаружил я сегодня в одном логе интересные заходы: [19/Sep/2019:03:58:20 +0300] "GET /women-parfum/proizvoditeli_adam-levine~afnan~tiffany~salvatore-ferragamo~larc~natori HTTP/1.1" 200 38926 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:20 +0300] "GET /women-parfum/proizvoditeli_adam-levine~tiffany~salvatore-ferragamo~larc~amzan~natori HTTP/1.1" 200 37936 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:23 +0300] "GET /women-parfum/proizvoditeli_adam-levine~tiffany~salvatore-ferragamo~larc~100-bon~natori HTTP/1.1" 200 38166 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:26 +0300] "GET /women-parfum/proizvoditeli_ajmal~adam-levine~tiffany~salvatore-ferragamo~larc~natori HTTP/1.1" 200 40672 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:27 +0300] "GET /women-parfum/proizvoditeli_adam-levine~adidas~tiffany~salvatore-ferragamo~larc~natori HTTP/1.1" 200 37876 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:30 +0300] "GET /women-parfum/proizvoditeli_adam-levine~agnes-b~tiffany~salvatore-ferragamo~larc~natori HTTP/1.1" 200 37833 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [19/Sep/2019:03:58:31 +0300] "GET /women-parfum/proizvoditeli_amouage~adam-levine~tiffany~salvatore-ferragamo~larc~natori HTTP/1.1" 200 40704 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" А ссылок таких в магазине нету. А есть только вида: <a class="checkb" onclick="javascript:location='https://site.ru/women-parfum/proizvoditeli_abercrombie-fitch~text'">text</a> Тоесть вроде это как фильтр. И там вроде как есть noindex, но гугл его чудесно увидел и пошел индексировать и придет еще и еще, так ка noindex тег - это "неиндексировать" а не "незаходить" . Таких ссылок в магазине только в одной категории если брать категорию + комбинацию пары брендов без доп атрибутов (брендов поярдка тысячи и вот каждый с каждым - миллион комбинаций только в одной категории). Совершенно ненужных мусорных страниц, на которые бродит бот. Да там каноникал и noindex, но он же будет туда все равно ходить повторно? А когда ему ходить то на нужные страницы ? Да и зачем уганять краулинговый бюджет на миллион холостых заходов? Непонятно мне совсем. И тут собственно вопрос в студию. А как это все прикрыть? Может отдать ему 404? Но тогда в магазине будет куча 404 страниц. Закрывать в robots по /*proizvoditeli_* но тогда пропадет часть посадочных, на которых есть текст и тайтлы и которые нужны. Че делать посоветуете господа ? UPD - чтобы совсем корректно не ajax ссылки, а js-ссылки, хотя мне кажется если у нас будет кусок ajax контента, он также проиндексируется. UPD2 - дабы не было холиваров. Эта проблема не с конкретным фильтром, а с любым, где есть автогенерация ЧПУ для параметров выборки.

А может стоит немного обмануть яндекс и добавить ему хвост обращения от СДЭК?

Или ко мне, после того как вам запорят магазин совсем)

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