хинт: этот функционал встроен в nginx - модуль geo. прописываете нужные сети и nginx сам рулит без дерганья бекенда и пхп. часть ip/сетей можно сразу 444-м сбрасывать.
У меня задача стоит не отбрасывать, а вычислять злодеев и пихать их в ipset, дабы они даже до nginx не доходили.
С двумя запросами в секунду в бан улетит весь гугл, яху и яндекс
У меня гугл матюгается даже если стоит 10 + burst 20 ибо он долбит непрерывно и никакие burst не помогут.
Так что включать limit_req на загруженном проекте имеет смысл только временно, чтобы побанить ботов. Причём скрипт обязательно должен проверять адрес на вхождение в CIDR известных поисковиков. Они довольно легко гуглятся.
Вот, к примеру, скрипт проверки, который использую я.
$GoodBots - массив CIDR поисковиков. Например
$GoodBots["Google"]="66.249.64.0/19";
$GoodBots["Google_1"]="209.85.128.0/17";
.... и так далее...
function isGoodBot($IP){ global $GoodBots; foreach($GoodBots as $BotName=>$CIDR){ list($Net,$CIDR_2)=preg_split("|\/|",$CIDR); $Mask=long2ip(pow(2,32) - pow(2, (32-$CIDR_2))); if (((ip2long($IP))&(ip2long($Mask)))==ip2long($Net)){ return $BotName; }; }; return false; };
zzzit: Так есть смысл партицировать значит :) И разнести по разным машинкам помельче, чтобы уход в даун одной как можно меньше юзеров задевал, а может и вообще не задевал ;)
Ну, на базе в продакшене как-то стрёмно тестировать.
Любое телодвижение, блокирущее таблицу посылает сейчас сервак в даун минут на десять. В это время несколько тысяч юзеров портят мне карму замысловатыми проклятиями.
По поводу терминологии - пардон, тупо странскрибировал )
Был бы дока в данном вопросе - наверняка бы и выразился правильно, да и не спрашивал бы :D
Стабильность raid - это миф. Вы ставите массив, у Вас повышается вероятность выхода дисков из строя, но при этом увеличивается хранилище данных, либо скорость доступа к ним. Т.е. теперь Вы защищаете не данные, а снижаете выросшую с количеством носителей вероятность потери данных или скорости доступа к ним. При этом, если raid находится в нормальной такой работе, то при развале массива система начнет тормозить, а это равносильно потере работоспособности системы.
Утверждение, мягко говоря, в корне ошибочное.
А уж ставить standalone на систему "в нормальной такой работе", вообще из области перверсий 😎
Пара десятков запросов в секунду для нормального сервака это вообще ниочём.
К примеру, на одном серваке у меня сейчас 224 mysql запроса в секунду к базе под 40 гиг. LA меньше единицы. Правда, сервак достаточно суровый.
И на чём всё это делать при 20 запросах - тоже без разницы.
Всё зависит от того - как вы эти запросы пишете и организации базы.
Сам уже давно с апача ушёл на лайти, а потом перешёл на nginx ибо в лайти не было необходимого мне функционала.
хинт: этот функционал встроен в nginx - модуль geo. прописываете нужные сети и nginx сам рулит без дерганья бекенда и пхп. часть ip/сетей можно сразу 444-м сбрасывать.
У меня задача стоит не отбрасывать, а вычислять злодеев и пихать их в ipset, дабы они даже до nginx не доходили.
С двумя запросами в секунду в бан улетит весь гугл, яху и яндекс
У меня гугл матюгается даже если стоит 10 + burst 20 ибо он долбит непрерывно и никакие burst не помогут.
Так что включать limit_req на загруженном проекте имеет смысл только временно, чтобы побанить ботов. Причём скрипт обязательно должен проверять адрес на вхождение в CIDR известных поисковиков. Они довольно легко гуглятся.
Вот, к примеру, скрипт проверки, который использую я.
$GoodBots - массив CIDR поисковиков. Например
$GoodBots["Google"]="66.249.64.0/19";
$GoodBots["Google_1"]="209.85.128.0/17";
.... и так далее...
И что м**ь ее так это за организация "Digital Ocean, Inc."
Ещё один рассадник заразы, наподобие Амазоновских Elastic Clouds
У меня, кстати, весь Амазон, Хетцнер и одна из сетей из Digital Ocean полностью забанены на уровне ipset
Так есть смысл партицировать значит :) И разнести по разным машинкам помельче, чтобы уход в даун одной как можно меньше юзеров задевал, а может и вообще не задевал ;)
Ну, на продакшене сейчас 12 гиг всего :)
Ну, на базе в продакшене как-то стрёмно тестировать.
Любое телодвижение, блокирущее таблицу посылает сейчас сервак в даун минут на десять. В это время несколько тысяч юзеров портят мне карму замысловатыми проклятиями.
По поводу терминологии - пардон, тупо странскрибировал )
Был бы дока в данном вопросе - наверняка бы и выразился правильно, да и не спрашивал бы :D
Nginx хорош для статики, php-fpm вообще лучше не использовать, обычный под апач куда как более приемлем.
Бу-га-га
🙄
Стабильность raid - это миф. Вы ставите массив, у Вас повышается вероятность выхода дисков из строя, но при этом увеличивается хранилище данных, либо скорость доступа к ним. Т.е. теперь Вы защищаете не данные, а снижаете выросшую с количеством носителей вероятность потери данных или скорости доступа к ним. При этом, если raid находится в нормальной такой работе, то при развале массива система начнет тормозить, а это равносильно потере работоспособности системы.
Утверждение, мягко говоря, в корне ошибочное.
А уж ставить standalone на систему "в нормальной такой работе", вообще из области перверсий 😎
Когда он же сам один сайт зафильтровал - прислал decreased
Когда из под фильтра вылез - increased
Сейчас вон, нашёл на нескольких сайтах по паре миллионов лишних страниц, про которые он же сам писал, что они уже год как проиндексированы в сайтмапе.
Теперь пишет, что найдено "чрезвычайно большое количество".
У них голова, часто не знает что ноги и руки делают.
Но траф гонит - а это самое главное. Остальное пофик :D
Skom, долгое время использовал xcache. Только недавно перешел на apc. Не жалею.
Ну, у меня причин искать альтернативы пока не было, посему и не дёргаюсь.