>>> Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов.
Ровно этот похдод проверяли пару месяцев назад. Кончилось тем, что нормальные пользователи начали пищать, а качальщикам - пофигу. Они и по 10 запросов вынесут сервер - разве что будет вместо одноно качальщика 2+
Я забил в поиск строку, открыл первые пару листов результатов - типичная операция при работе с форумом. 38 запросов за 30 секунд...
А ведь запросто несколько пользователей могут оказатсья за одним IP, а качальщик будет просто каждые 5 минут устанавливать новое подключение, получать от провайдера новый адрес или менять прокси.
>>> В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД).
Во-первых, не постоянно, а только для страниц пролетевших мимо кэша, для 95% случае (или какова там у нас эффективность кэша) никаких дополнительных проверок не надо.
Во-вторых, "десятки тысяч записей" - жупел. Один дополнительный SELECT по _идексированой_ таблице это вообще не проблема, даже если там и в самом деле несколько десятков тысяч записей - благо таблицу можно периодически чистить.
>>> А как это сделать на уровне сервера? Apache? Вот в чём вопрос.
См. выше. Делал я зимой такое, пострадали невиновные. И я выше написал почему.
Веб-сервер _не_знает_ про кэшированые страницы, а это _надо_ для принятия решения.
>>> И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
Это не "пока", это вообще единственное решение.
Пиковая загрузка - не так страшна, в дневное время при работающем мониторинге нет проблем отстреливать качальщиков руками. Можно привлечь модераторов и т.п.
А вот со средним уровнем нагрузки сделать ничего нельзя. Движок будет обрастать фичами и становиться все тяжелее, количество посетителей будет увеличиваться - в конце концов ромба загнется под собственным весом и без всяких качальщиков.
Среднее количество просмотров страниц на одного посетителя очень хорошо кореллирует с нагрузкой - когда сервер начинает подтормаживать и отдавать страницы медленнее чем привык пользователь - человек просто уходит.
У нас три проблемы:
1) Корректно интегрировать отстрел качальщиков в движок (плагин или типа того) не получается и не факт что вообще возможно внедриться в потрха друпала на таком уровне.
2) Изменение кода движка для отстрела качальщиков повлечет за собой невозможность обновления движка.
3) Ресурсов на поддержку "модифицированой" версии движка у нас нет. Если продолжать "ломать" движок - придется переписывать каждую новую версию друпала под себя - мы потеряем возможность обновления и установки секьюрити-фкисов от производителя. Дефейс и кража персональных данных через свежиу уязвимости Drupal'а - вполне вероятный вариант при таком развитии событий.
>>> Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов.
Ровно этот похдод проверяли пару месяцев назад. Кончилось тем, что нормальные пользователи начали пищать, а качальщикам - пофигу. Они и по 10 запросов вынесут сервер - разве что будет вместо одноно качальщика 2+
Я забил в поиск строку, открыл первые пару листов результатов - типичная операция при работе с форумом. 38 запросов за 30 секунд...
А ведь запросто несколько пользователей могут оказатсья за одним IP, а качальщик будет просто каждые 5 минут устанавливать новое подключение, получать от провайдера новый адрес или менять прокси.
>>> В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД).
Во-первых, не постоянно, а только для страниц пролетевших мимо кэша, для 95% случае (или какова там у нас эффективность кэша) никаких дополнительных проверок не надо.
Во-вторых, "десятки тысяч записей" - жупел. Один дополнительный SELECT по _идексированой_ таблице это вообще не проблема, даже если там и в самом деле несколько десятков тысяч записей - благо таблицу можно периодически чистить.
>>> А как это сделать на уровне сервера? Apache? Вот в чём вопрос.
См. выше. Делал я зимой такое, пострадали невиновные. И я выше написал почему.
Веб-сервер _не_знает_ про кэшированые страницы, а это _надо_ для принятия решения.
>>> И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
Это не "пока", это вообще единственное решение.
Пиковая загрузка - не так страшна, в дневное время при работающем мониторинге нет проблем отстреливать качальщиков руками. Можно привлечь модераторов и т.п.
А вот со средним уровнем нагрузки сделать ничего нельзя. Движок будет обрастать фичами и становиться все тяжелее, количество посетителей будет увеличиваться - в конце концов ромба загнется под собственным весом и без всяких качальщиков.
Среднее количество просмотров страниц на одного посетителя очень хорошо кореллирует с нагрузкой - когда сервер начинает подтормаживать и отдавать страницы медленнее чем привык пользователь - человек просто уходит.
У нас три проблемы:
1) Корректно интегрировать отстрел качальщиков в движок (плагин или типа того) не получается и не факт что вообще возможно внедриться в потрха друпала на таком уровне.
2) Изменение кода движка для отстрела качальщиков повлечет за собой невозможность обновления движка.
3) Ресурсов на поддержку "модифицированой" версии движка у нас нет. Если продолжать "ломать" движок - придется переписывать каждую новую версию друпала под себя - мы потеряем возможность обновления и установки секьюрити-фкисов от производителя. Дефейс и кража персональных данных через свежиу уязвимости Drupal'а - вполне вероятный вариант при таком развитии событий.