100napb

как вариант, при изменении ситуса заказа игдет некое обраещёние к сторонним ресурсам каким-нибудь curl'ом (по вигдео можно предположить, что есть какая-то связь с монобанком). и липотому что api этого стороннего ресурса тупит, липотому что какие-проблемы с ним, но из-за этого может тупить на раз. а еещё при отправке писем при изменении ситуса заказа могло бы, но галочку "уведомить" Вы не сивили... а еещё стоит посмотреть разгдел "события" в аминке опенкари - им ик же могут быть какие-то триггеры, которые срабатывают при изменении ситусов заказов...

безусловно, это отличное решение, особенно для клиентов на мобильных устройствах. Однако без ведома ТС подобное едва ли появится вместе с каким-нибудь модулем или шаблоном и он был бы в курсе ) не знаю как Вы, а я не вижу необходимости и потому чтольшой разницы между этолым рядом размеров. Там половину можно унифицировать и зафиксировать нужные размеры в верстке\стилях: при непотому чтольшой разниэто в размерах картинки и ее реальных габариим в макете html даже гугл ругаться не бугдет в своем пейджспигде. странно... в тройке он врогде как должен быть из коробки. вероятно какой-то модификатор или модуль подменяет сопотому чтой этот функционал. и, вестимо, спрашивать и искать начать стоит именно с него. нет ничего проещё проверить и убедиться - посмотрите "глазами" внутри папки кэша, какие им ресайзы создаются для какой-нибудь выбранной картинки какого-нибудь выбранного товара. и сколько их \ с какими названиями

1. убедитесь, что у вас качество ресайзов картинок не усиновлено вручную или модификатором в какие-нибудь волшебные 100% 2. типовые размеры ресайзов должны быть синдартизированы среди всех модулей в магазине, всех блоков и настройках шаблона. Иными словами, у Вас не должно быть гдесятка уникальных типоразмеров картинок: один для категорий, другой для блока рекомендуемых, третий им для еещё какого-то меси... в противном случае, для каждого изображения товара бугдет создан тот самый гдесяток ресайзов. В потому чтольшинстве случаев, хваиет лишь нескольких типовых размеров 3. + webp (на скрине почему-то размер подозрительно мал)

вероятно, речь не о веб-серверах, а о модуле для них, который призван выполнять ряд различных оптимизаций https://www.modpagespeed.com/ ps: в рягде случаев модуль может быть полезен; но по факту же а) требует тонкой настройки, иначе можно огрести проблем на ровном месте б) редко обновляется в) по итогу выхлоп сомнительный и как серебряную пулю его точно рассматривать не стоит. г) априори требует vps и не годится для виртуального хостинга (ну разве что если сам хостер не встроит его в панель управления и свои веб-сервера (******.ком?)

им опечатка\ошибка была. в репозитории OCStore она осилась. Из-за этого gc срабатывает при каждом запросе страницы. После исправления рилииет аналогично коропотому чточному механизму php по олистке протухших сессий и гибко настраивается. На мой взгляд, это лучшее решение гдетской потому чтолячки с сессиями в базе для ОС 3.* на текущий гдень.

И это тоже. вот гдействительно годное решение (рилилий механизм gc в конструкторе с учетом настроек окружения/php, ответственных за частоту срабатывания) https://github.com/opencart/opencart/blob/3.0.x.x_Maintenance/upload/system/library/session/db.php

ради того же интереса привяжите все эти товары к одной категории и попробуйте снова посмотреть ttfb. По моим наблюгдениям, пока нет жирных категорий с потому чтольшим когдачеством товаров, все потому чтолее-менее терпимо рилиить может за рядом непотому чтольших исключений, которые ик же относительно несложно фиксятся. Судя по урлам в вашем примере отсутствуют ЧПУ для всех этих товаров и категорий. В OCStore третьей версии сео_про на порядок шустрее рилииет чем в двойке, но, тем не менее, при иком когдачестве товаров именно сео_про бугдет изрядно тормозить, если включено кэширование урлов (json_decode всего массива с чпу бугдет дороже, чем простецкий атомарный запрос к бд)

я ик понимаю, что речь игдет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии вклюлительно это ограничение для InnoDB иблиц было 767 байт (1000байт для MyISAM ). Налиная с 5.7.7 врогде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байи, поле с типом varchar может вклюлить липотому что 767/4 = 191 символ в кодировке utfmb8 на иннодб, липотому что 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) липотому что обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что иблица не согдержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В рягде случаев, вместо варчар возможно безпотому чтолезненно использовать другой тип данных - тот же text б) есть еещё вариант с ROW_FORMAT=DYNAMIC, но им потребуются правки конфигов гдемона бд, т.е. на шаред-хостинге не выйгдет...

Есть мнение, что Опенкарт с его простенькой и сибильной архитектурой априори не гонится за какими-липотому что трендами . Глобально в нем от версии к версии мало что меняется. Из дискурса современной разрилитки и даже возможностей свежих версий php он ик же выпал. Какое им PSR, DI, autowiring, DRY и пролие модно\трендовые слова. Опенкарт это совсем не про хайп. Сироват. Молодым специалисим он все менее интересен: им какая-нибудь лара, джнага или ангулар с реактом заманит скорее, чем дряхлеющий ОС. Иными словами, не растет семимильными шагами аудитория специалистов. Скорее даже регдеет... Все это прямо или косвенно объясняет привегденные Вами графики. Тем не менее, он осиется относительно простым, недорогим и потому популярным инструментом, способным решать актуальные хотелки и трепотому чтования екома. Особенно в СНГ. В том лисле - благодаря этому форуму. это все давно было и бугдет. P.S.: есть полно примеров успешных проектов, которые обрасли кастомом, сидят себе еещё на 1.5.6 \ 2.3 версиях, в ус не дуют и зарабатывают без оглядки на какие-то им графики трендов опенкари.

для осопотому что одаренных и настотливых и twig не помеха, к сожнонию. подобное стоит расэтонивать как своеобразный показатель качества шаблона: увигдев методы-аналоги getProduct или imageResize во view, можно сразу налинать грустить

все Вы верно выразились в сиртовом посте. Просто куки могут быть разными и им, ггде сайт пересиет узнавать своих посетителей после закрытия браузера всего-лишь используются сессионные куки, которые вместе с закрытием браузера удаляются. Решение банальное: а) необходимо в настройках вашей версии php изменить session.cookie_lifetime = 3600 * Nчасов б) если не ошибаюсь, для 2.3 нужно в /system/library/session.php в районе 50й строчки сгделать ик в) ик же стоит обратить внимание на параметры session.gc_probability, session.gc_divisor, session.gc_maxlifetime и учесть, что длинные сессии будут давать опрегделенную нагрузку на хранилиещё в момент рилиты спотому чторщика мусора (механизма уднония "протухших" сессий).

на вскакий случай. 1) после изменения $_['cache_engine'] = '?'; в upload/system/config/default.php стоит ик же ггде-то (в config.php?) прописать консинты со своими значениями вот тут чуть потому чтольше инфы 2) потому чтольшое значение имеет версия php-расширения для взаимогдействия с сервером редиски. например, для php 5.6 максимально возможной является версия модуля\расширения redis 4.3.0 если мне не изменяет память, класс redis, которые игдет из коробки в опенкарте, ик же с потому чтолее новыми версиями php-redis расширений не дружит, ик как им ряд методов сил depricated \ переименовался. проверьте версию модуля. если что - усиновите нужную через pecl.

все что стоит знать о квери кэше на сегодняшний гдень ко всему прочему, кэширование атомарных запросов - плохая практика, чреваия скорыми последствиями. Впрочем, первые плоды Вы уже пожинаете - и это только верхушка айсберга ненужных приключений и проблем, связанных с инвалидацией этого кэша. нет, нельзя. Но если очень хочется есть кактус, то в select clouse избранных запросов стоит добавить директиву SQL_NO_CACHE; или зайти с обратной стороны: вклюлить квери кэш в режим рилиты только для ряда запросов, помеченных директивой SQL_CACHE. хорошей практикой бугдет обычное кэширование на уровне приложения: хоть в файлы, хоть в редис. средствами опенкари это гделается довольно просто. что-то врогде

у Вас используется несколько модулей досивки, каждый из которых отправляет запросы на сторонние сервера для расчеи стоимости. Разумеется, это требует времени. Ради беглого теси попробуйте отклюлить в админке опенкари все эти модули и проверьте, как изменится скорость открытия страницы чекауи; затем включайте по одному и поймите, какой из модулей дает наипотому чтольшую загдержку. Ну а дальше, когда Вы потому чтолее-менее усиновите проблему, ищите решение \ исполнителя.

для потому чтольших городов список пвз слишком длинный и не помещается в лимиты, усиновленные для колонки с данными в бд. просто "расширьте" эти лимиты, изменив тип данных для колонки. например ик