LNShadow: Ну на абузу то надо отреагировать, поэтому удаляем. Не то что для спокойствия: под абузоустойчивостью понималось что хостер не будет сразу блокировать/отключать проект, а дает время, обычно 24 часа на ответ и действия с нашей стороны. А не так что на нас посыпались абузы и нас тут же заблокировали
зачем реагировать на жалобу если она не обоснованная? или вы и вправду вирусы распростроняете?
ivan-lev: Den73, не уверен, что мы друг друга поняли.
Робот может и сделает то же количество обращений, но он не будет одномоментно (с короткими промежутками, пока сервер не успел обработать, добавлять ему ещё пару) грузить сервер кучей запросов. Всплесков не будет.
Используемые ресурсы в единицу времени уменьшатся при уменьшении request per second (или увеличении таймаута между запросами, что по сути одно и то же)
но у хостеров единица времени например явно не минута, обычно cpu собирают штатными средствами ядра OS - системный аккаунтинг, ротацию делают обычно раз в час а результаты выводят суточные в таком случае я не понимаю как увеличение интервала может повлиять на исп. ресурсов в целом скорее всего просто размажет нагрузку.
можно конечно протестировать и посмотреть, но если у хостера совсем другие алгоритмы и инструменты то мы может только делать предположения.
Ну на абузу то надо отреагировать, поэтому удаляем.
Не то что для спокойствия: под абузоустойчивостью понималось что хостер не будет сразу блокировать/отключать проект, а дает время, обычно 24 часа на ответ и действия с нашей стороны.
А не так что на нас посыпались абузы и нас тут же заблокировали
зачем реагировать на жалобу если она не обоснованная? или вы и вправду вирусы распростроняете?
А что мешает набрать в Яндекс, к примеру : хостинг Зенон и увидите их контакты...
http://yandex.ru/yandsearch?text=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3+%D0%B7%D0%B5%D0%BD%D0%BE%D0%BD&clid=1955453&lr=43
И звоните себе на здоровье.. если у них сервер(ы) завалились, то телефон точно работать будет, там вам все и расскажут...
сколько там линий на телефоне, вы и вправду думаете то что есть свободная ячейка во время лежки?
если не вирусы то зачем удалять?
Den73, проблема в том, что их сайт/биллинг никогда не должы лежать, не должны быть связаны с клиентской инфраструктурой.
что значит не должны? у вас в договоре есть такая формулировка или вы сами придумали?
а в чем вообще проблема? полежит и вернется.
Многие хостинги не хотят брать к себе пирамиду, что делать?
правильно делают
4000Рублей оО
да за эти деньги можно дедик и спать спокойно.
не правда, что бы спать спокойно нужно еще админа к дедику прикупить а это не меньше 100$ только за присмотр.
ivan-lev
я понял о чем вы, на сервере без жесткого оверсела все это будет бесполезно там например 20 rps или 1 rps обрабатывается одинаково быстро.
Den73, не уверен, что мы друг друга поняли.
Робот может и сделает то же количество обращений, но он не будет одномоментно (с короткими промежутками, пока сервер не успел обработать, добавлять ему ещё пару) грузить сервер кучей запросов. Всплесков не будет.
Используемые ресурсы в единицу времени уменьшатся при уменьшении request per second (или увеличении таймаута между запросами, что по сути одно и то же)
но у хостеров единица времени например явно не минута, обычно cpu собирают штатными средствами ядра OS - системный аккаунтинг, ротацию делают обычно раз в час а результаты выводят суточные в таком случае я не понимаю как увеличение интервала может повлиять на исп. ресурсов в целом скорее всего просто размажет нагрузку.
можно конечно протестировать и посмотреть, но если у хостера совсем другие алгоритмы и инструменты то мы может только делать предположения.
ivan-lev
там за всем не уследишь это же костыли по сути, проще сменить тариф на более подходящий.
а если все же что то делать то нужно проанализировать все логи например за неделю, то что привел тс этого явно недостаточно.
""правильные" роботы слушаются."
а толку, это же просто интервал запросов, сколько им нужно сделать request - столько они и сделают все равно просто с другим интервалом.
используемые ресурсы пользователем будут такие же в итоге.