да код довольно индивидуален чтоб его скидывать как есть.
надо под свои nginx конфиги делать.
главное примерно понять суть:
в разделе где nginx отдает статику (может ведь быть как-то по другому реализовано, например nginx отдает все, кроме .php) добавить подмешивание куки в заголовки:
location ~* \.(css)${ add_header Set-Cookie "notbot=1;Path=/;Max-Age=31536000";}
и также в конфиге каждого нужного виртуалхоста (ну или глобально, опять же кому как захочется) делаем проверку типа такой:
if ($block_post){ return 403;}
и дальше, еще выше на уровне http {} вставляем:
map "$remote_addr" $localip{ default 0; "ip сервера 1" 1; "ip сервера 2" 1;}map "$request_method:$localip:$cookie_notbot" $block_post{ default 0; "POST:0:" 1;}
что переводится на человеческий как: сделать $block_post = true (чтоб потом там где надо выдало 403 ошибку) в случае если: метод запроса был POST, если ip того кто запрашивал не равен одному из ip сервера и если нет куки notbot
проверка локальных ip нужна т.к. тот же wordpress может делать запросы типа POST /wp-cron.php и чтоб их не отшивало на 403 Forbidden
кому выключается?
да к примеру интернет-магазин с какой-то windows програмулиной, которая должна делать какие-то свои POST запросы к сайту. правка наличия товаров или кто его знает что еще.
это редко, но бывает что необходимо. можно также вместо выключения просто добавить нужный ip в белый список.
ну и конечно можно модифицировать это все как вздумается под свои задачи.
да просто в скрипте используются относительные пути скорей всего.
вот и выходит, что если по обычному запускать, из его же папки, то все в норме.
но крон запускает этот скрипт находясь в /root - домашнем каталоге юзера root
короче не в кроне дело, а в скрипте самом
либо править все на абсолютные пути, либо можно попробовать в самом верху добавить:
chdir(pathinfo($_SERVER['SCRIPT_FILENAME'],PATHINFO_DIRNAME));
т.е. определить полный путь к скрипту, взять из него имя каталога и перейти в него. дальше уже можно относительными путями оперировать.
если выполняется, то выполняется... надо проблему искать не в кроне.
возможно php скрипт заканчивается какой-то ошибкой - потому и нет "эффекта".
можно пропробовать вручную:
заходим в /etc/cron.d и создаем там файл с любым именем.
в первой строке пишем MAILTO=[ящик куда пойдет письмо в случае чего]
дальше:
* * * * * root [путь к php] [путь к скрипту]
периодичность запуска естественно ставим какую нужно.
если скрипт закончится с ошибкой, на ящик придет все что он там написал.
проблема еще можеть быть в самой строке запуска. например пишете просто php. у вас работает, но у крона может не работать, лучше писать полный абсолютный путь.
также и со скриптом самим. вы его может запускаете из его папки и внутри скрипта используются относительные пути. а потом из под крона оно может оказаться что запускается из другой папки - опять же, лучше использовать абсолютные пути. или вверху скрипта задать какой-то ROOT='путь' и дальше в скрипте использовать не относительные пути, а ROOT плюс что там нужно...
короче надо смотреть вживую, без этого можно лишь догадываться что там у вас не срабатывает.
у моих подопечных (shared хостинг) по-умолчанию включается защита на уровне nginx, которая при всех POST запросах проверяет наличие одной куки, которая ранее ставится когда запрашиваются .css файлы.
боты ничего такого не запрашивают и соответственно получают лишь 403 ошибку когда POST'ят что-либо.
таким образом отлично отшиваются и брутфорсы и спам-посты. причем независимо от cms, будь то wordpress или что-угодно другое.
всегда суть одна и та же: что-то нехорошее делается обычно при POST'е, и боты обычно не качают контент сайта (.css).
но конечно изредка кому-то действительно нужны какие-то автоматические пост запросы, тем защита выключается.
работает так не первый год, wp сайтов сотни, их постоянно брутфорсят, но нагрузки никакой нет, взломов нет, одни плюсы :)
сменил днс на те, что пришли с доступами к впс
меня одного терзают смутные сомнения на этом моменте? :)
подозреваю, что вам к vps дали dns - те, через которые сама vps'ка должна все ресолвить. типа как 1.1.1.1 или 8.8.8.8
а вовсе не те, на которые надо вешать домены свои.
ну включите логику на мгновение: каким образом те dns будут узнавать какие домены вы себе на vps добавили?
у вас есть какая-нибудь возможность править dns записи именно на этих dns, что вам дали? подозреваю что нет... собственно что тогда удивляет? как оно должно все работать по вашему?
нужно либо на своей же vps'ке (vps'ках) подымать dns сервер, либо какой-то сторонний сервис использовать, тот же яндекс, cloudflare.
а если по существу? кто-то жаловался на недостачу настроек или нехватку ресурсов? вроде нет.
отказоустойчивость? если был ddos, то чем дедик был бы более отказоустойчив? точно так же слег бы.
но! через сколько бы часов сайт снова поднялся в случае дедика?...
сколько времени бы у него ушло на осознание что происходит, почему лежим. сколько времени на привлечение этого самого администрирования со стороны, на вникание в вопрос, разбирательство что там как устроено/настроено. ну и плюс собственно решение вопроса.
а теперь что же было в случае "плохого" премиум хостинга:
админы всегда держат руки на пульсе своих серверов. в случае чего, сразу сами приступают к решению вопроса, зная как у них там что устроено и что нужно делать, левой рукой отбиваясь от клиентов отмашками "видим, решаем, не мешай".
короче, 2 часа за 5 лет это отлично я считаю. а сколько часов даже за год будет недоступен сайт у владельца (в большей степени по его же вине) , прислушавшегося к "грамотным" советам и взявшего себе vps или дедик?
ну серьезно. если опыта нет, то какое-то время оно конечно даже будет работать, но проблемы рано или поздно появятся. и решение их наверняка затянется на гораздо большее время.
достаточно тут же на форуме полистать соседние темы - типа перешел с shared'а на vps... не работает dns, сайт не работает, пойду спрошу на форуме... и буду терпеливо ждать. да уж :(
30000 (100 000 в пике) запросов в секунду ... MYSQL и такой нагрузкой у меня не вышло
может дело не в самой mysql, а в том что это все именно по сети должно происходить?
что именно не вышло? у вас было два сервера, один mysql, второй его клиент и между ними какой канал был, 100мбит или больше?
если да, то подозреваю дело именно в этом.
взглянем к примеру:
т.е. если взять ваши 100тыс req/s, то даже просто минимальными 1500-байтными пакетами обмениваться - 100мбит канала для этого впритык.
но каждый mysql запрос у вас наверняка куда больше одного pps занимает. даже если предположить 10 пакетов на каждый запрос, то и гигабитного канала маловато будет.
суть в том что даже если данных там у вас передается не особо много, но проблема именно в количестве запросов, которые нужно протолкнуть по сети.
а значит такой mysql сервер должен быть подключен минимум 10г каналом. и кто знает сколько там клиентов и какие каналы у них.
чисто предположение мое... кто знает что там на самом деле не вышло.
во-первых не понятно каким образом связаны php и html файлы.
подозреваю что никак. и что php в этом html файле вообще не исполнятся?
если исполняется, то проще:
вверху html файла где-нибудь добавляем <?require_once('php_файл');?>
и ниже уже можем использовать переменные из этого php файла:
<div id="A"><?=$mamba?></div>
<div id="B"><?=$text?></div>
<div id="C"><?=$pay?></div>
если всеж php в html файле не работает (это чисто статика), то можно конечно вставить с помощью яваскрипта например или можно сделать чтоб что-то генерировало эту статику с уже вставленными $mamba и т.д. из php скрипта (но смотря как часто оно должно обновляться)... короче надо четкое понимание ТЗ. иначе это все сплошное гадание.
а если выключить кэш полностью (Widget Output Cache или что там)?
будут постоянно страницы дольше секунды генерироваться?
если да, то верно выше замечено - слишком много скриптового хлама. кэш плагин конечно же работает, но он ведь откуда-то должен брать готовые страницы, т.е. один заход медленно, потом из кэша... до установленного таймаута.
короче это норма. хотите быстрей - надо смотреть что там особенно все затормаживает и беспощадно сносить. ну либо еще вариант - тупо наращивать скорость железа. частота процессора в первую очередь, на бегете видел несколько аккаунтов - все в районе 2.5ггц, что далеко не быстро.
еще не раз наблюдал когда понаставят тем/плагинчиков и в них какие-то толи закладки, толи кто их разработчиков знает что оно такое. но суть в том что при каждом заходе на страницы происходят исходящие запросы чего-то со сторонних сайтов - это естественно ужасно влияет на скорость отклика. особенно если реально был бэкдор и тот сайт куда оно ломится уже в ауте либо тормозит.
ну либо если сайт редко обновляется можно сделать чтоб кэш очень очень долго хранился. сейчас действительно, клацаю по страницам - один заход типа 1.5сек, второй уже в районе 80мс.
