NotSlow

В чем особенность? Ровно также как и jpg, css, js... Как - зависит от того где сайт работает сейчас. Кто ж знает как организовано у вас. Если статику nginx отдает, то в нем и задавать заголовки для кэша. Если apache, то через .htaccess море примеров в инете. Задавать/нет и на сколько - вам решать. Если просто ради оценки по pagespeed, то ставьте. Если эти самые js скрипты часто меняются, то наверное не стоит. Это в любом случае лишь рекомендация для браузеров. Некоторые из без этого сами все подряд больше чем надо кэшируют, чем только мешают тем кто сайты делает/меняет часто. А можно браузер и под себя настроить. У меня например после закрытия весь кэш удаляется. Чтоб независимо что там по кэшу сайт сообщает, я просто прегружаю браузер и открываю сайт как в первый раз, все качается с хоста, а не из кэша берется.

Кстати в соседней теме https://opencartforum.com/topic/186817-problema-s-otobrazheniem-fotografiy-tovarov/ Тоже сайт на thehost.ua и тоже заметно тормозит. Повод задуматься...

Тоже проблемы не наблюдаю

Какая проблема? Куда смотреть? Что сейчас не правильно?

И сайты разные, не только opencart? Тогда вообще не факт, что opencart сайт ваш причина. Возможно заражен какой-то другой, а пострадали все на аккаунте. Или "на хосте" - в смысле на разных аккаунтах на одном хосте? Ну тогда точно надо переносить на другой. В общем все еще не ясно что вы тут хотите на форуме Чистите вручную, переносите на другой хост. Если там не повторится, значит проблему решили. Не умеете? Значит обращайтесь к тому кто умеет. Можно и мне в личку написать, могу глянуть.

*:25 значит на всех ip слушает. Да и если говорите меняли порт и все работает, то что остается? Точно блокировка где-то дальше, что тут поделать... Можно продолжать настаивать чтоб передали вопрос кому-то более сознательному в поддержке. Но проще конечно забить и переехать. Ну или хотябы почтой переехать как выше писал. Есть (видел по крайней мере раньше) варианты за $1/мес или около того. На тех же lowendbox/lowendtalk посмотреть. Главное пробить ip по спам базам прежде чем селиться: https://mxtoolbox.com/blacklists.aspx

А кто тут по вашему знать может? Доступов к сайту и логам нет ни у кого... Скорей всего сами и занесли заразу через модули или скрипты сомнительного происхождения. Или кто-то занес, кому могли давать доступ. Можно попытаться спросить у хостера, но это не их обязанность разбираться. Если проблема появилась недавно, то возможно есть бэкап, где все в норме? Это самое простое решение.

Покажите еще lsof -i -n -P | grep :25 Вдруг там окажется, что listen есть... но только на 127.0.0.1 например Это возможный вариант, при котором локально у вас все работает, а снаружи нет. Если всеж listen именно внешний ip есть, то покажите еще iptables -S

Если уверены, что iptables или еще что-то точно не блокирует у вас, то значит остается блокировка где-то между vps и интернетом. Т.к. из вне порты у вас там действительно недоступны (скрины ниже). Кроме поддержки vps никто вам не поможет. А если они отказываются, то выходов лишь 2: 1) Переехать полностью. 2) Если обосновались и не хочется переезжать, то перенести только почту на другую (где угодно и самую дешевую) vps, где нет таких блокировок. MX запись домена соотв. направить на новый ip Но конечно понадобится еще чтобы почта с сайта уходила через тот ваш smtp. Можно даже установить себе msmtp (или подобный smtp прокси), которая будет ловить всю локально отправляемую почту (по php mail например) и пересылать на указанный smtp с авторизацией. Вот только из-за блокировки вы скорей всего не сможете с ним связаться... я и с таким сталкивался. В таком случае достаточно сменить порт на какой-то нестандартный и все будет работать. Т.е. на почтовой vps открывается 25, 465, 587 как обычно и плюс один нестандартный, по которому будет связь от vps с сайтом. Морока... потому лучше конечно первый вариант. Ну или продолжать требовать от поддержки чтоб разобрались.

Да дело ваше конечно. Если сайт для pagespeed делаете, то ладно. Но выше вон пример как вы чуть не потеряли потенциального клиента, который мог не дождаться 10сек открытия страницы и просто закрыть сайт Повторные заходы да, терпимо. Но если походить по сайту, то много страниц без кэша очень долго генерируются. Главное чтоб не стало только хуже Если это будет 1-2ядерная 2ггц vps

Да есть. Тоже сразу заметил. Не похоже что стоит какой-то кэширующий модуль. Выглядит будто php opcache небольшого размера и многие страницы с "холодным стартом", очень долго генерируются. А повторные уже быстрее... на сколько ~400мс можно назвать быстрым.

У тех кто брал еще вечность не закончилась, пока рано судить.

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

Поиск всегда надо начинать с логов. Если там есть что-то про memory например, то да, дело в лимитах на память. Например мелкие фотки проходят, а на крупных упирается в ограничения. Но надо смотреть что еще за ошибки есть.

Напишите в поддержку hostpro.ua Боитесь побьют вас или что? Она, поддержка, для того и поддержка. Или в личку. Можно скринами показать что там как, подскажу куда нажать.

Или еще вариант - кто-то удалил кэш фоток. И теперь какое-то время будут тормоза пока они снова не пересоздадутся. Хотя при этом будет приличная CPU нагрузка, а у вас не ясно есть ли она или нету.

Вам же сказали какие - php процессы Можно зайти по ssh и запустить top например. А что конкретно за процессы и что они там делают - это хостеру видней. Может у вас там какие-то cron задачи запускаются, возможно они что-то качают откуда-то, а тот недоступен - вот и висит все. Может это именно php процессы от заходов на сайт ваш. Надо как минимум в логи заглянуть. Если вам про нагрузку на процессор хостер ничего не говорил, то полагаю процессы эти висят просто так, не нагружают cpu. Значит скорей всего опять же среди php скриптов где-то выполняется запрос к стороннему хосту, который видимо не отвечает или тормозит сильно. Не имея доступов, точней подскажет только гадалка.

Как вариант - cloudflare подключить. И их защитой от ботов отбиваться. Но... Не факт что осилите :] Но самое правильное - начать с изучения логов и от этого уже дальше что-то делать.

вопросы: 1) 15гб что именно занимает? весь сайт целиком с базой? только mysql база 15гб? или всеж речь про папку image? т.е. чисто фоток 15гб? 2) в чем именно проблема? зачем уменьшать? не хватает места на диске (тариф нынешний например до 15гб) и чтоб не платить больше за следующий хотите ужаться? или место есть, но не хватает inodes (есть ограничение на количество файлов)? если речь именно про фотки, то 16тыс на 15гб - это же меньше 1мб на товар... это не сказать что и много, куда там уменьшать. тут опять же, чтобы что-то советовать надо понимание сколько именно оригиналы весят, а сколько ресайзы. как выше уже писали, возможно оригиналы надо пережать, возможно в ресайзах там по 10 копий фоток разного размера и надо уменьшить количество копий. ну а если проблема не в гигабайтах, а в количестве файлов фоток, то надо просто переехать на другой хост, где нет таких ограничений. по vps - может у него уже и так vps, кто знает... просто место на диске нельзя добавить, а переносить нет желания. а если сейчас shared, то vps же выйдет еще дороже, может задача стоит расходы не увеличить хотяб... а вы предлагаете и расходы на сам хостинг увеличить, да плюс далеко не у каждого пингвины на аватарке надо ведь еще разбираться в этом всем и поддерживать. а если нет знаний - это опять же лишние расходы на поддержку.

Вы бы написали хостеру, спросили нет ли у них... возможно они не такие беспечные :]

вы бы просто backup откатили, чем разбираться что не так или тем более кого-то чужого пускать разбираться :-\

Так было всегда или вдруг стало? Возможно этот случай: Открыта куча разных вкладок и месяц браузер не перегружался... https://opencartforum.com/topic/102951-kak-uvelichit-vremya-sessii-v-adminke/#comment-990255 Также создайте любой файл, например i.php с текстом: <?phpinfo();?> Откройте браузером сайт/i.php Ctrl+F и найдите там session.gc_maxlifetime Что сейчас за значение стоит?

ох уж этот народ с 5000 открытых вкладок в браузере где-то на 1000х задаст вопрос на форуме и пропадет... сейчас наверное где-то в районе 2000х, через месяц вернется как ни в чем не бывало. а мы тут зря переживаем, версии разные предполагаем...

белый экран - это в 99% случаев php fatal error при отключенном отображении ошибок. но в логах должно быть видно в чем ошибка