100napb

не удивительно... в этом модуле механизм получения случайных товаров реализован через одно место: если утрировать до сути, то что-то вроде select ... from oc_product where... order by rand(). Слова "скорость", "быстро" и "order by rand()" в sql-запросах - несовместимы. Если кратко, то подобные запросы работают примерно так: возьмем список из всех-всех товаров магазина, добавим рядом с ними вымышленную колонку со случайным числом, а потом отсортируем по этой вымышленной колонке. Какие индексы, вы что... этот механизм обречен тормозить и сколько-нибудь шустро работает только если только кол-во товаров <100шт. Если будете заказывать разработку своего модуля, который должен получать случайные товары - учтите, что подобных запросов в базу он делать не должен!

почти пальцем в небо (вы случайно засветили имя базы и ссылку на домен).... у Вас папка /admin/ не переименована случаем?

типичная ошибка, которая случается, когда делаешь бэкап через админку опенкарта и затем пытаешься развернуть его на другом (чистом?) сайте\другой площадке А все дело в том, что бэкап средствами опенкарта копирует только данные. Не структуру данных. Так и у Вас: таблицы myoc_translation не оказалось на площадке-реципиенте. Или она вдруг называется по-другому теперь. И при попытке восстановить данные с такого "неполного" бэкапа случается облом - т.к. в бэкапе нет инструкций, как создать эту таблицу, только сами данные... Как решить? А) проще всего делайт полноценный бэкап. либо через phpmyadmin, либо средствами самого mysql (через mysqlbackup). б) Разворачивайте бэкап так же: либо через пхпмайдмин, либо напрямую через консоль

эта ошибка не всегда говорит о падении службы бд. Например, соединение может быть принудительно закрыто сервером (по таймауту или иным причинам) попробуйте изменить в конфигах параметр wait_timeout и увеличить его хотя бы до 30сек, например. У Вас он сейчас 10. Вдруг.. ) и да. Как Вам писали выше: изучите файл системного лога центоса (message.log который). А именно: попытайтесь сопоставить время ошибки со временем событий из него - вдруг проглядели.

эм... а Вы правда хотите, что бы у Вас сайт РАБОТАЛ под двумя разными доменными именами? Вы разве не хотите оставить основным только один, латинский или кириллический домен? Просто сейчас у Вас странно: сайт открывается по кириллической ссылке. Без переадресации на латинский домен. Но в то же время все внутренние ссылки сайта ведут на латинский домен ) Получается, существует две совершенно одинаковые страницы на двух разных доменах. Сео-шники оценят... Нередко кириллический домен используют в качестве дополнительного - с него просто сразу же идет переадресация. UPD: ко все прочему, не совсем корректно настроен https в самом опенкарте: все ссылки на сайте ведут на http - версию; при переходе по ним сразу же делается автоматический редирект на https - версию. надо что бы ссылки сразу были на https. Для этого, как минимум, в файлах config.php в корне сайта и в папке /admin убедитесь, что адрес сайта прописал с https

а его нет в готовом виде. надо считать исходя из истории\операций\значений строк в данной таблице для каждого клиента. не проверял запрос, т.к. нет бонусных баллов под рукой, но посчитать можно как-то так, например: в принципе, все достаточно просто. со старой БД развернуть в новую БД или рядом с ней две временные таблицы, содержащие oc_customer_reward и oc_customer. Скриптом выше посчитать результаты и присвоить их уже клиентам в новую БД.

oc_customer_reward

если Вы прям уверены, что на сервере ничего не тормозит и он прям быстро отвечает, то, как вариант, может быть большое кол-во значений в выпадающих списках фильтра и тормозит тупо браузер в процессе рендринга страницы. Тот факт, что в логах медленных запросов (вы же лог БД смотрели, ага?) Вы ничего подозрительного не нашли не означает, что их нет: может быть вместо 1-2шибко медленных быть несколько тысяч достаточно быстрых. В любом случае, вариантов может быть масса. Вплоть до сторонних модулей в админской части, которые обращаются ко внешним ресурсам. что бы хотя бы понять наверняка, что тормозит: сервер или клиент, сделайте скрин наподобие того, что в спойлере ниже. Для этого нажать ф12 в браузере, перейти на вкладку сеть\network, открыть страницу, которая тормозит и сделать скрин с результатами: что бы было видно время ответа сервера и время, затраченное на отрисовку страницы.

как потенциально возможный вариант: у Вас включен ЧПУ ссылка на категорию имеет вид типа domain.tld/category_299_name/ ссылки на дочерние категории выглядят типа domain.tld/category_299_name/subcategory1, domain.tld/category_299_name/subcategory2 Ваш авторский калькулятор оформляете внутри стандартного модуля HTML-содержимое Создаете новый макет в "дизайн" - "схемы", для макета указываете путь что-то вроде "/category_299_name/" (сработает как маска\регулярное выражение для всех подкатегорий) привязываете в макете в любом удобном положении модуль HTML-содержимое со своим калькулятор

все относительно. 1) тут им предстоит определить минимум для небольшого набора значений. очень небольшого 2) я действительно перепроверил результаты из стартового поста. Они актуальные с обновленным запросом тут, в мускуле\марии, проще и такой проблемы не случится. кэширование подзапросов действует только в рамках одного родительского запроса. на другие не распространяется. За эту оптимизацию отвечает параметр optimizer_switch='subquery_cache=OFF'. Гуглится легко. Строго говоря, мысль была простая: уйти от дорогих зависимых подзапросов в сторону более оптимизированных джоинов. И пока, вроде как, идея жизнеспособна ) Спасибо за замечания.

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

можно заморочиться. да. но стоит ли оно того? вроде затраты копеечные. даже если отзывов на проекте будет пару тысяч, думаю, картина не сильно изменится

отсюда нельзя? можно. тут получается нечто вроде цикла: для каждого значения\строки p.product_id, которое передается в этот подзоапрос будет вычисляться price. мой вариант не делает зависимого запроса (заменен джоином) и возвращает в точности тот же набор данных, что и нативный.

Согласен. Есть нужный запрос\требование к результата функции во входящем $data - логично джоинить нужные блоки, будь-то акции, рейтинг, регулярная цена или что-то иное. Тем более, эти дополнительные вычисления однозначно требуют значительных ресурсов и времени. Тем более, что даже в нативной структуре блоки вычислений вполне себе обособлены и находится в select-секции запрашиваемых переменных в качестве связанных подзапросов (DEPENDENT SUBQUERY, что не шибко быстро). Но главное обособлены. И их, в принципе, не трудно подключать\отключать. Например как в Вашем примере. *тумбс_ап* эм... а зачем? потеряется нормализация данных, например, в том случае, если товар в нескольких категориях. тем более джоинить ряд мелких таблиц типа product_to_category и накладывать в них дополнительные ограничения-условия на данные в where секции очень дешево, а если есть все нужные индексы - так и вообще... спасибо за отклик.

Здравствуйте. Думаю, многие знают как выглядит типичный sql-запрос этой функции. и ни для кого не секрет, так же, что в категориях с большим количеством товара этот запрос уверенно претендует на роль аутсайдера - выполняется ощутимо медленнее других и лидирует в списках медленных запросов в каком-нибудь слоу-логе или дебаггере. В том числе из-за этого запроса может сильно увеличиваться ttfb для ряда категорий страниц в опенкарте. И че, прям сильно тормозит? Предлагаю убедиться самим. В том же phpmyadmin`e выполните: Я попробовал немного переписать этот запрос. Сделать его более оптимальным. Не претендую на лучшее решение, но, кажется, оно ощутимо быстрее. В некоторых ситуациях в 2 - 5 раз. Для тех кто поленился тестить в пхпмайадмине, примеры могут быть такими* *взяты с разных серверов разных проектов; у всех железо и настройки субд разные, не говоря уже про специфику каждого проекта и данные в таблицах скидок\акций; индексы так же не проверялись. но общий вывод очевиден; Что с этим дальше делать? Пригодится ли это кому-нибудь \ сообществу? я привел лишь один из вариантов sql-запроса, который может быть сгенерирован функцией getProducts: там еще есть варианты с тэгами и прочим. Переписать весь этот конструктор внутри функции, собирающий запрос на основе входящего массива $data, не так быстро\просто для полноценного теста. Во всяком случае для меня лично. Плюс, если не ошибаюсь, запрос в этом виде существует достаточно давно и тянется от одной версии к другой. И, вероятно, к его структуре привязывается достаточно большое количество модулей\модификаторов. Исторически сложилось (с). Может быть и не стоит его трогать вовсе... кому надо, тот найдет другие способы, как от него избавиться или заменить на что-то свое, что бы ускорить страницы. P.S. прошу прощения, если что-то где-то проглядел или в чем-то ошибся. собственное, потому тема в курилке))

вставлю свои 5копеек. так как php у Вас работает через fpm, то для разных версий php-fpm у Вас разные конфигурационные файлы. Например, /opt/php73/etc/php-fpm.d/www.conf и /opt/php70/etc/php-fpm.d/www.conf в каждом конфиге php-fpm есть директива listen, которая указывает апишник и порт, либо путь до сокета, на котором "жить" fpm. Вероятнее всего, они у Вас указаны разные для разных версий пхп Помимо listen есть еще listen.mode, listen.owner, listen.group, user, group - эти параметры должны быть для 7.3 идентичные тем, что для 7.0 (на 7.0 ведь все работает) и, наконец, так как все это дело проксирует nginx, то в его конфиге, в блоке server, который обрабатывает Ваш сайт (скорее всего конфиг внутри подпапки vhosts) должна быть секция\локейшн для обработки php и проксированием на адрес php-fpm. Судя по ошибкам, могу предположить два варианта в локейшене проксирующем php неверно указан индексный файл по-умолчанию (fastcgi_index index.php). или в самом блоке server конфига не указана директива index index.php index.html; Странно прост, что во всех ошибках у Вас .html ("/var/www/user/data/www/blabla.com/omega-3-i-dobavki/index.html" is not found) идет попытка проксировать обработку php туда, где ее не ждут... т.е. адрес в location'е nginx'а не соответствует текущему адресу действующего php-fpm. Переключить версию пхп переключили, а в конфигах nginx'a не исправили. P.S.: чудесам с ноутбуком и совпадениям верю меньше, чем логам и конфигам.

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

вероятно Вам стоит обратиться к автору, в тему поддержки модуля тык

нет таблицы ar_productday в базе данных. видимо, у Вас ранее стоял какой-то модуль\функционал, связанный с отображением\скидками или что-то подобное, завязанное на дни недели или даты. А потом вдруг (переезд на другой сервер?) забыли эту таблицу перенести, в которой этот модуль хранит свои данные. Ищи таблицу в старой базе, что бы перенести данные. Либо можете переустановить модуль, что бы он создал эту таблицу заного. Как временное решение - отключить в админке опенкарта этот фунционал. ПС: я понятия не имею, какой модуль или тема использует таблицу с таким названием. Это не из стандартного опенкарта точно.

попробуйте в файле /system/library/session.php сделать две правки. а) б)

а вам точно нужна картинка в кнопочке весом 5мб? ))) уберите для начала ее...

посмотрите в сторону $this->session->data['currency']

смотря в каком месте\файле Вы делаете округление. Если в контроллере products.php, то курс\конвертация там обязательно учитывается на основе значения из сесси пользователя (какая валюта у него стоит в магазине). Может быть это как-то пересекается с Вашим округлением... Вот после подобной строки уже ничего не стоит делать с ценой, т.к. тут и символ валюты есть и вообще после этого в data['price'] не число, а строка... $data['price'] = $this->currency->format($this->tax->calculate($product_info['price'], $product_info['tax_class_id'], $this->config->get('config_tax')), $this->session->data['currency']); Если не разобрались еще окончательно, можете прикрепить файл с Вашими правками. А то гадать дольше...

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