100napb

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

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