Yoda

А что вас смущает, это я так понимаю, заголовок у 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 до этого шла про сессионные куки и мы ее тут просто в паблике продолжили. А господа имеют привычку слышать звон и бежать на зов природы...

Так таки умрет? О чем дальше разговаривать?

Конечно, хочу как ваша компания тоже стать альтертнативно одаренным.

Следовательно, когда браузер закрывается, сессионные cookie сразу же удаляются. Это же ваши слова! Я о чем говорю? Именно об этом! Переобулся в прыжке.

Модераторы, или кто тут посты трет. Угомонитесь! Тут достаточно важный вопрос про время жизни кук... Еще раз повторяю пост! Куки в бразуере живут после закрытия бразера, если корректно настроен параметр. session.cookie_lifetime integer session.cookie_lifetime указывает время жизни cookies, отправляемого в браузер клиента, в секундах. Значение 0 означает, что cookies будут валидны до закрытия браузера. По умолчанию равно 0. См. также session_get_cookie_params() и session_set_cookie_params(). Вот официальная документация: https://www.php.net/manual/ru/session.configuration.php#ini.session.cookie-lifetime Вместо того чтобы тереть все под корень, разберитесь в проблематике, и немного альтернативно-одаренных на место ставьте, которые рассказывают бред.

Что вы говорите, а сколько там от magento осталось, сколько это стоило, и сколько стоит кластер на котором это вертится, озвучьте сразу.

Опустим за скобками, историю про github, а вот про ускорение мадженто и выше возможности, будьте добры, поведайте, что вы имели ввиду. Покажите к примеру магазин на миллион-полтора товаров на magento, который вы ускоряли, и который держит 250 000 запросов в день с семикратным запасом прочности.

Еще как относится. Так как кука твой умрет, если бразуер закрыть и открыть.

а session.cookie_lifetime у тебя скока ?

https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=18266 Есть более интересные варианты. Но это лишняя информация.

ООП - не не слышал. Это совет почти как. Если вам нужны данные из базы. Вставьте код в tpl.