Евгений Крупченко

Евгений Крупченко
Рейтинг
165
Регистрация
27.09.2003
Интересы
хостинг без тормозов

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

Как именно - надо смотреть предметно что конкретно там происходит. Если параллельно много скриптов долбят mysql - логично ограничить их количество. Сделать чтоб весь этот процесс проходил более однопоточно и оставались ненагруженные ядра для работы всего остального. Чисто железом, не меняя ничего программно, вопрос не решить - все равно будет все та же 100% загрузка, но просто другое количество времени. Можно лишь минимизировать ущерб (тормоза в других задачах помимо обновления) ограничив количество этих тяжелых потоков.

Конечно можно за ту же цену взять больше ядер/меньше частоту... и пусть даже пару часов обновления превратятся в час, но все остальное время ведь обычные запросы будут проходить медленней.

Есть процессоры 8-10-ядерные аналогичной 4+ггц частоты, но очевидно стоить это будет заметно дороже... и опять же, 2ч станут 1ч, но все равно моменты тормозов со 100% загрузкой никуда не уйдут.

-= Serafim =- #:
Использовать Cloudflare или любой подобный сервис или нанять админа.

Только более внимательного, не такого как здешний модератор.

Хотя он же и сам своего рода админ... 888 😎

Отключили же за атаку не НА, а ОТ.

Т.е. взлом или бэкдор, через который вы стали участником атаки на кого-то. Что делать? Лучше контролировать что там у вас происходит. Сложно что-либо советовать без понимания что там у вас и как, но как минимум надо посмотреть продолжаются ли попытки слать те пакеты. Если да, то чем - что-то "левое" запущено или тупо скрипты/бэкдоры на сайте. Смотреть все логи и т.д... короче лучше пользоваться shared хостингом, раз такие вопросы по форумам спрашиваете.

Dram :
где ошибаюсь?

Так вот же где:

Dram :
ВПС

😏

На shared'е обычно сами бы перенесли и все сделали как положено.

Dram :

Открываю сайт - он открывается, все норм, делаю изменения (по ФТП) ничего не вижу нового.

Захожу в админку ВП - там данные о старом сервере (версия пхп и т.п.).

В FTP клиенте может же быть вбит домен, а может сразу ip.  Заливаем по фтп (именно на правильный новый ip) в корень какой-нть test.txt и открываем браузером - он наверняка не откроется, значит копаем почему браузер игнорирует hosts. Может vpn какой-то включен, может прокси, кто знает что там у вас. Самое быстрое - попробовать в другом браузере.

Полагаю у вас хром, т.к. firefox обычно адекватно реагирует на ctrl+f5 - сбрасывает свой dns кэш тоже.

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


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

В данном конкретном случае у вас проблема чисто с браузером - он игнорирует записи в hosts временно (может нормально перегрузиться полностью нужно) или постоянно (какая-то хитрая настройка/фича/баг/плагин).

Если отвечать на прямой вопрос про единичный скрипт, выполняющийся 5сек (а не выдумывать условия типа ab -c 300 - долбежка 300 запросами одновременно по этому скрипту), то да почти без разницы будет это nginx или apache.

На скорость выполнения (повторяю, именно в этом случае - один запуск долгого 5-секундного скрипта) гораздо сильней влияет версия php, настройки php.ini (наличие opcache, обработка ошибок, модули подключенные и т.п.), скорость процессора (не мощность, не производительность, а именно single-thread скорость, зависящая от архитектуры/свежести ядер cpu и тактовой частоты), чем микро-разница между apache и nginx.

Также стоит учесть, что тот же apache с php может взаимодействовать ну очень по-разному (mod_php или cgi например). И то, что если выключить в apache поиск и выполнение .htaccess, то он не так уж радикально будет отставать от nginx (ну может кроме занимаемой памяти).

Плюс очень сильное влияние оказывает работа opcache в php. Поэтому без подробного сравнения всех конфигов нельзя ничего однозначно утверждать. Я вот даже когда делал тесты ниже столкнулся с загадкой почему под nginx/php-fpm скрипт выполнялся примерно на 100мс дольше... оказалось скрипт довольно древний и под php7.4 выдавал кучу deprecated сообщений в процессе выполнения. Когда заглушил эти ошибки в php.ini, результат пришел в норму.

Так что нельзя вот так безапеляционно заявлять, что nginx быстрей apache. Очень много нюансов и очень зависит от конкретных задач.

Итак:

Я с ходу не нашел на столько медленного и тяжелого скрипта, взял вот этот:

http://www.php-benchmark-script.com

Запускал у себя на домашнем роутере, а не где-то на сервере в инете, где постоянно бы влияли на результат соседи.

Он в это время совершенно ничего не делал и можно считать замер более-менее точным.

Проц E5-1630v4 с постоянной частотой 3.8-4.0ггц (не в спящем режиме каком-то).

Везде выставил одинаковую версию php 7.4 и одинаковые настройки php.ini и делаю 3 прохода подряд.



1) Запускаю bench.php из коммандной строки, т.е. под php-cli без включенного opcache в php.ini


Итого отправная точка: ~0.585сек рисует результат сам скрипт и около 0.59сек итого рисует нам time



2) Opcache в php-cli - это конечно не тоже самое, когда php запущен все время (php-fpm или mod_php например) и держит в памяти опкоды. Однако даже на время выполнения одного скрипта он может немного повлиять на результат.

Запускаю тоже самое, с opcache.enable_cli=1 в php.ini


Что изменилось: ~0.515сек (0.07сек выигрыш - 13%) и около 0.53сек итого по результату time

Т.е. однозначно, включение opcache даже в cli дает прирост. Какой именно - очень очень сильно зависит от самого скрипта и от их количества.

Естественно под веб-сервером, если php правильно настроен и запущен всегда с выделенным достаточным объемом памяти под opcache, и если скрипт будет не один, а к примеру wordpress с кучей php скриптов - результат вкл/выкл opcache может быть сильно более заметен.

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

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



3) nginx -> apache/mod_php


В итоге видим примерно те же 0.525-0.530сек по результату скачивания скрипта wget'ом с веб-сервера.

+/- в пределах погрешности, хотя и самую кроху шустрей, чем из под cli - ведь opcache тут уже работает полноценно как и должен.

Повторяю, на большем количестве скриптов результат был бы более заметен (не в пользу php-cli).



4) nginx -> php-fpm


Снова как видим все в пределах погрешности измерений ~0.525сек



Так какой правильный вывод? Именно в этом случае разницы не будет - хоть 0.5сек, хоть 5сек скрипт будет выполняться +/- одинаково не только из под apache или nginx, но даже из под php-cli (только если opcache.enable_cli будет выключен, то получится немного заметнее медленней).


Но! Не путаем это с реальными сайтами. В который раз повторюсь, там где не одиночный долгий скрипт, а много-много php файлов - там работа opcache будет куда более заметна. И в зависимости от нагрузки (количество запросов в секунду прилетающих на сайт) уже может вылезти различие между apache и nginx. Но это не касается обычных мелких сайтов, на которых и 1 запроса в секунду не приходит. Для них важней иметь пусть меньшее количество, но более высокочастотных ядер процессора. У сайтов же с большим траффиком все не так, не нужно их приплетать куда не следует. Да, там по итогу меньше нагрузка и больше скорость (суммарная на всех, а не у каждого отдельно взятого запроса) может получиться на 16-ядерном 2ггц процессоре, чем на 4-ядерном 4ггц. И какие-то минимальные (в обычных ситуациях) преимущества nginx могут также всплыть более ярко.

Еще раз - с уверенностью можно сказать, что один 5-секундный скрипт будет выполняться одинаково и под apache и под nginx. При условии конечно же одинаковых настроек php и если под apache совсем уж плохо все не настроено.

dokker555 :
насколько это вообще безопасно?

На 24 :)

Почему здесь спрашиваете? Кто тут может знать на сколько все безопасно у хостера этого? У него и спрашивайте... он конечно же ответит на 100% все супер.

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

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

Осенью делал 3 заказа у разных продавцов суммарно на немыслемые 4 бакса. Все были магическим образом объединены в один и да, доставлены новой почтой бесплатно.

Сперва все заказы отправляются по своим трекномерам, а потом они заменяются на один общий.


https://novaposhta.ua/tracking/international/cargo_number/aenm0003466678npi

Без понятия как это работает, но факт. Сколько там нынче минималка у новой почты для пересылки по стране, бакса два небось?... 🤔

Вам с вашими царскими $14  думаю переживать вообще не стоит. Доставят.

Потому что надо прикладывать, а не прилаживать.

И что в итоге вам известно о том, кому заплатили?

Телефон
Скоро...
Артём Ломакин #:
ИП оформим чутка позже

На все это нужен паспорт... который будет чуть позже.


Тут даже нет вопросов к пацану, а скорей вопрос адекватности его "клиентов". Такие и на авито переводят непойми кому на карту и потом ждут с моря погоды.

Т.е. спрашивать по каким-то форумам, давать кому-то доступы - это нормально.

А просто обратиться к хостеру чтоб тот посмотрел что не так или просто сделал дамп - что-то из разряда фантастики?


Это первое что стоило бы сделать.

Второе:

phpmyadmin у вас от панельки какой-то? Я бы скачал последнюю версию и закинул на сайт. Т.к. а) маловероятно, но какой-то баг в phpmyadmin б) вы скорей всего увидите в логах ошибки, если такие там имеются (лога phpmyadmin от панели скорей всего вам не увидеть). Запросто может просто оказаться какой-то default параметр в php или специально зачем-то сильно урезанный.

Дальше. Кроме phpmyadmin есть же другие инструменты, например:

https://www.adminer.org/#download

Также, если даже нет ssh, то можно попытаться из под php запустить mysqldump и может он сделает дамп правильно.

Кроме вас и вашего хостера никто тут не видит что именно и кто запрашивал в моменты этих всплесков.

Если вы не знаете куда смотреть, просите того, кто должен знать - хостера.


А так, конечно же первым делом access логи вебсервера.

Во-первых чтоб убедиться, что действительно дело в 135.131.185.35.bc.googleusercontent.com, а не чем-то/ком-то еще.

Во-вторых смотрите что конкретно оно там с вас скачивает такое объемное. Может фото-видео тяжелое.

И что вообще за 135.131.185.35.bc.googleusercontent.com - за ним ведь скрываться может любой ip, даже совершенно не связанный с гуглом. Если действительно что-то левое - просто бан (любым способом) и все, зачем ходить по каким-то форумам, спрашивать кого-то кто понятия не имеет что у вас там происходит...

Всего: 517