i3bepb

Я не так выразился, да он может существовать, но не проходить MX DNS проверку - https://ru.wikipedia.org/wiki/Запись_MX. Т.е. заранее проверяется, что к такому домену не закреплен ни один почтовый сервер. Вот есть онлайн проверка - https://dnschecker.org/mx-record-validation.php?query=test.com

Валидный в плане допустимых символов, а плане существования домена test.com - нет. И фактически на такой email все равно не отправить почту т.е. он нереальный, а это в случае если надо отправлять почту на этот email, а не просто для галочки нужен = не валидный email.

Если поверх еще стоит nginx, который отдает статику, то в принципе Apache удобен, что он использует .htaccess, который есть по умолчанию в движке и как правило когда надо что-то в маршрутизации настроить много решении на базе .htaccess Это решение без nginx не используют, т.к. php-fpm обрабатывает именно php и отдавать статику вообще не умеет, но могу ошибаться. Поэтому как правило когда говорят php-fpm, то сразу подразумевается поверх nginx. Был такой опыт, когда для быстродействия переводили с apache на php-fpm, ситуация улучшилась больше запросов стал держать сервер, но тут же зависит от специалиста, который настраивает, если он знает как готовить php-fpm, а apache не знает, то явно у него php-fpm будет работать быстрее. Не слышал про такой. Я всегда выбираю php-fpm, но потом как правило проблемы с сеошниками например, которые умеют писать правила для .htaccess и когда им говоришь, что у тебя не используется .htaccess, то они становятся беспомощными.

Дак у Вас не только поиск тормозит, а впринципе все старницы, например Моторные масла открылась за 18 сек, а страница товара, вообще открылась за 22 сек. Ищите и оптимизируйте медленные sql запросы, как правило проблема в них.

Тогда возможно строка сериализации банально битая, например данные очень большие и строка длинная, а когда делался дамп, то он его порезал хотя как такое возможно. А как делали дамп БД? Новая ошибка о том, что в запросе не задано значение для поля invoice_no, но и в структуре таблицы значение по умолчанию не предусмотрено в итоге как бы отсутствует обязательное поле. А как прошлую ошибку решили? Знаете возможно код, который дает ошибки плохо написан и там проблемы отсутствия значения по умолчанию не предусмотрены, просто код писался с другим режимом работы сервера БД, в mysql есть такой параметр sql_mode он как раз задает поведение сервера в разных ситуациях и одна из ситуации как раз когда не задано значение обязательного поля. Вот статья на русском про это - https://habr.com/ru/post/166411/. Я думаю в этом направлении надо копать )

Ошибка говорит о том, что он не может десерилизовать какие-то данные. Сериализованные данные обычно хранять в БД. Например следующий массив: $arr = [ 'amount' => 12, 'field1' => 'we are the champions', 'field2' => 'мы три еще чемпионые' ]; сериализуется в следующую строку: a:3:{s:6:"amount";i:12;s:6:"field1";s:20:"we are the champions";s:6:"field2";s:37:"мы три еще чемпионые";} Я специально подобрал строку на англ. и рус. по кол-ву символов одинаковую, но если посмотреть как определил длину то англ. он написал s:20 т.е. норм там 20 символов включая пробелы, а рус. он написал s:37. Дак вот проблемы могут быть как писал @spectre Я только хочу уточнить, что это не значит, что что-то не скопировали, а скопировали не в той кодировке, для нормальной работы с кириллицей нужна кодировка utf-8, как в БД, так и в php. Т.е. когда пытается десериализовать данные, он ожидает одно кол-во данных, а получает другое. Вообщем надо копать в сторону кодировки.

А какую ошибку выдает? Скорее всего не хватает прав у пользователя, которым подключаетесь к БД. Если у Вас хостинг, а не выделенный сервер, то скорее всего Вам не дадут таких прав т.к. сервером баз данных пользуетесь не только Вы, но и другие кленты и тогда Вам надо обращатся в техподдержку, чтобы они сами включили лог и тогда там надо согласовать работу Вас и техподдержки. Техподдержка должна включить лог, а Вы должны выключить кэш на сайте и походить по нему, чтобы пошли тяжелые запросы. Да это секунды, Я обычно начинаю с 3 сек. и уменьшаю постепенно 2,1... В документации написано, что можно указывать вплоть до микросекунд, но примера нет, видимо дробной часть. А для оценки нормальных запросов можно взять такую величину, например загрузка страницы 500 мсек я думаю более менее нормально, дак вот за эти 0.5 сек. должен успеть отработать веб-сервер и php и все sql запросы на этой странице. Дак вот сколько на странице sql запросов бывает, как Вы думаете? Ну пусть запросы это 70% от всего времени загрузки страницы 0.5*0.7=0.35 сек. на все запросы на странице, ну т.е. нормальные запросы должны выполнять за сотые секунды, поэтому если что-то переваливает даже за 1 сек. уже беда, а если за 3 сек., то подавно.

)))

Я выдвену гипотезу. Тормоза на сайте были всегда, а в тот день когда были чудеса просто "протух" кэш, чему доказательство: Т.е. если бы не кэш, то сайт тормозил всегда и соответственно одно из самых простых решении проблемы это установить модуль кэша, а он уже установлен! Люблю поумничать.

А в браузере в панели разработчика (F12), может есть какие-то ошибки когда кликаете. Вообще отлаживать пытались или "ой не работает", лапки сложили и побежали на форум писать!?

Еще на странице товара постоянная какая-то загрузка скриптов в цикле происходит. Это происходит из-за загрузки вопросов-ответов, там редирект на страницу товара и в итоге страница товара загружается в div на странице товара и так повторятся по кругу. Со временем все начинает тупить, вообщем это более важная проблема так по мне, которую необходимо поправить.

Вообще надо посмотреть в панели разработчика в браузере как вообще запрос за файлом видео, что возвращает - F12, вкладка network

Возможно папка public_html это корень и в браузере ссылка на эту папку будет /, соответственно url будет <p><video controls="" src="/video/IMG_videotest.MP4" width="640" height="360" class="note-video-clip"></video></p>

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

А в логе БД есть этот запрос, т.е. он там выполняется?