Перевожу на общедоступный: товарищ (гражданин/господин/мистер) админ хочет тонко-дипломатично сказать, что данную тему можно переименовать (воспринимать) как:
1. Продолжение сериала: "Новый сервер 2009".
2. Очередная акция: "Убей качальщика - спаси сервер".
Отстреливаем по мере сил, несколько адресов ежедневно.
С сентября количество просмотров страниц утроилось, а количество пользователй заходящих на сайт выросло в 4 раза (это по данным liveinternet.ru, там вроде бы только анонимы). Конечно, где-то должен быть предел насыщения и стабилизация, но если в ближайшие 6 месяцев мы будем рости теми же темпами что и прошедшее полугодие - начиная с осени вопрос поизводительности будет действительно поднят вновь.
Лимит хттп коннектов на интервал времени (к примеру, 50-70 запросов за 5 минут) не поможет в борьбе с качками, и как на это отреагируют боты поисковиков?
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
>>> Лимит хттп коннектов на интервал времени (к примеру, 50-70 запросов за 5 минут) не поможет в борьбе с качками, и как на это отреагируют боты поисковиков?
Нет, не поможет.
Лет 10 назад начала эпоха keep-alive, и в одном коннекте может идти много запросов.
"Качки" запрашивают _только_ страницы, причем в большинстве своем - плохо кэшированые.
Нормальный юзер как правило запрашивает хорошо кэшированые страницы, картинки, стили и т.п.
Итого получается, что 5 запросов от "плохого" пользователя хуже чем 50 запросов от человека.
Т.е. даже если мы ограничим как-то количество запросов к страницам, мы все равно не сможем отделить ботов от людей.
Человек запустивший браузер с созраненным набором табов может сгенерировать десятки запросов в течении буквально секунд - но ничего страшного не произойдет...
С поисковиками проще - им можно культурно намекнуть о желаемой нагрузке, да и работают они намного интеллектуальнее.
Поисковики работают по сайту круглосуточно, но ничего страшного от этого не происходит.
Поисковики ежедневно высасывают сотни мегабайт (бывет - и больше гигабайта), однако из-за их алгоритма работы они не создают серьёзной нагрузки, т.к. выкачивают наиболее часто изменяемые страницы, чем становятся похожи на "обычных" пользователей.
Качальщики же запускают "тупые" качалки, которые сразу лезут "вглубь", т.е. запрашивая старые страницы. Алгоритм кэширования движка настроен на 95% пользователей, которым не нужны (постоянно) записи пятилетней давности. Кроме того, закэшировать "всё" - технически невозможно, т.к. номинальный объём сайта исчислятся более чем миллионом различных страниц (поисковики "знают" лишь около 200 тысяч самых "адекватных"). Потому, когда качальщик начинает "поднимать ил", запрашивая древние страницы, заведомо отсутствующие в кэше - наличие кэширования уже играет против движка, т.к. древняя страница всё равно больше никому не понадобится потом, а время на её кэширование потратится.
Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов. В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД). А как это сделать на уровне сервера? Apache? Вот в чём вопрос. И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
>>> Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов.
Ровно этот похдод проверяли пару месяцев назад. Кончилось тем, что нормальные пользователи начали пищать, а качальщикам - пофигу. Они и по 10 запросов вынесут сервер - разве что будет вместо одноно качальщика 2+
Я забил в поиск строку, открыл первые пару листов результатов - типичная операция при работе с форумом. 38 запросов за 30 секунд...
А ведь запросто несколько пользователей могут оказатсья за одним IP, а качальщик будет просто каждые 5 минут устанавливать новое подключение, получать от провайдера новый адрес или менять прокси.
>>> В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД).
Во-первых, не постоянно, а только для страниц пролетевших мимо кэша, для 95% случае (или какова там у нас эффективность кэша) никаких дополнительных проверок не надо.
Во-вторых, "десятки тысяч записей" - жупел. Один дополнительный SELECT по _идексированой_ таблице это вообще не проблема, даже если там и в самом деле несколько десятков тысяч записей - благо таблицу можно периодически чистить.
>>> А как это сделать на уровне сервера? Apache? Вот в чём вопрос.
См. выше. Делал я зимой такое, пострадали невиновные. И я выше написал почему.
Веб-сервер _не_знает_ про кэшированые страницы, а это _надо_ для принятия решения.
>>> И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
Это не "пока", это вообще единственное решение.
Пиковая загрузка - не так страшна, в дневное время при работающем мониторинге нет проблем отстреливать качальщиков руками. Можно привлечь модераторов и т.п.
А вот со средним уровнем нагрузки сделать ничего нельзя. Движок будет обрастать фичами и становиться все тяжелее, количество посетителей будет увеличиваться - в конце концов ромба загнется под собственным весом и без всяких качальщиков.
Среднее количество просмотров страниц на одного посетителя очень хорошо кореллирует с нагрузкой - когда сервер начинает подтормаживать и отдавать страницы медленнее чем привык пользователь - человек просто уходит.
У нас три проблемы:
1) Корректно интегрировать отстрел качальщиков в движок (плагин или типа того) не получается и не факт что вообще возможно внедриться в потрха друпала на таком уровне.
2) Изменение кода движка для отстрела качальщиков повлечет за собой невозможность обновления движка.
3) Ресурсов на поддержку "модифицированой" версии движка у нас нет. Если продолжать "ломать" движок - придется переписывать каждую новую версию друпала под себя - мы потеряем возможность обновления и установки секьюрити-фкисов от производителя. Дефейс и кража персональных данных через свежиу уязвимости Drupal'а - вполне вероятный вариант при таком развитии событий.
Размер кеша - ограничивается собссно движком, или же объемом диска сервера?
Да и с модификацией движка - нет функции вести логи промахов мимо кеша, с сохранением ИП? Если же делать модификацию - то никто не мешает внедрить свой код в функцию собссно генерации странички в случае ее отсутствия в кеше, и юзать глобальные переменные движка, а то и переменные ПХП... ИМХО при переходе от версии к версии переменные особо меняться не должны, а переносить - патчем...
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
>>> Размер кеша - ограничивается собссно движком, или же объемом диска сервера?
При приближении эффективности кэша к 100% объем БД будет возрастать нелинейно - тупиковый путь развития который опять же потребует железа.
>>> Да и с модификацией движка - нет функции вести логи промахов мимо кеша, с сохранением ИП? Если же делать модификацию - то никто не мешает внедрить свой код в функцию собссно генерации странички в случае ее отсутствия в кеше, и юзать глобальные переменные движка, а то и переменные ПХП... ИМХО при переходе от версии к версии переменные особо меняться не должны, а переносить - патчем...
Есть желающие заняться реализацией этих идей во временном промежутке от полугода и далее?
Выше шла речь именно об этом: у нас нет человеческих ресурсов на нормальную поддержку своего форка. Нехватает человеко-часов, знаний, навыков и т.п.
Если бы здесь был форум веб-программистов - было бы вероятно иначе. Но тут ремонтники. А ромба как веб-приложение давно уже миновала уровень наколенной поделки в потрохах которой может разобраться любой энтузиаст смежной сферы за пару вечеров колупания методом научного тыка.
Насчет эффективности кеша - оно-то понятно... Интересовало, чем именно вызван лимит - возрастающей нагрузкой на базу/апач при запросах к большому кешу либо же все упирается в дисковое пространство...
Попробую качнуть движок и глянуть ему в код...
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
Перевожу на общедоступный: товарищ (гражданин/господин/мистер) админ хочет тонко-дипломатично сказать, что данную тему можно переименовать (воспринимать) как:
1. Продолжение сериала: "Новый сервер 2009".
2. Очередная акция: "Убей качальщика - спаси сервер".
>>> 1. Продолжение сериала: "Новый сервер 2009".
Это скорее к впоросу: куда и с какой пользовой потратились деньги.
>>> 2. Очередная акция: "Убей качальщика - спаси сервер".
Отстреливаем по мере сил, несколько адресов ежедневно.
С сентября количество просмотров страниц утроилось, а количество пользователй заходящих на сайт выросло в 4 раза (это по данным liveinternet.ru, там вроде бы только анонимы). Конечно, где-то должен быть предел насыщения и стабилизация, но если в ближайшие 6 месяцев мы будем рости теми же темпами что и прошедшее полугодие - начиная с осени вопрос поизводительности будет действительно поднят вновь.
ex-K9
Лимит хттп коннектов на интервал времени (к примеру, 50-70 запросов за 5 минут) не поможет в борьбе с качками, и как на это отреагируют боты поисковиков?
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
>>> Лимит хттп коннектов на интервал времени (к примеру, 50-70 запросов за 5 минут) не поможет в борьбе с качками, и как на это отреагируют боты поисковиков?
Нет, не поможет.
Лет 10 назад начала эпоха keep-alive, и в одном коннекте может идти много запросов.
"Качки" запрашивают _только_ страницы, причем в большинстве своем - плохо кэшированые.
Нормальный юзер как правило запрашивает хорошо кэшированые страницы, картинки, стили и т.п.
Итого получается, что 5 запросов от "плохого" пользователя хуже чем 50 запросов от человека.
Т.е. даже если мы ограничим как-то количество запросов к страницам, мы все равно не сможем отделить ботов от людей.
Человек запустивший браузер с созраненным набором табов может сгенерировать десятки запросов в течении буквально секунд - но ничего страшного не произойдет...
С поисковиками проще - им можно культурно намекнуть о желаемой нагрузке, да и работают они намного интеллектуальнее.
Поисковики работают по сайту круглосуточно, но ничего страшного от этого не происходит.
ex-K9
Поисковики ежедневно высасывают сотни мегабайт (бывет - и больше гигабайта), однако из-за их алгоритма работы они не создают серьёзной нагрузки, т.к. выкачивают наиболее часто изменяемые страницы, чем становятся похожи на "обычных" пользователей.
Качальщики же запускают "тупые" качалки, которые сразу лезут "вглубь", т.е. запрашивая старые страницы. Алгоритм кэширования движка настроен на 95% пользователей, которым не нужны (постоянно) записи пятилетней давности. Кроме того, закэшировать "всё" - технически невозможно, т.к. номинальный объём сайта исчислятся более чем миллионом различных страниц (поисковики "знают" лишь около 200 тысяч самых "адекватных"). Потому, когда качальщик начинает "поднимать ил", запрашивая древние страницы, заведомо отсутствующие в кэше - наличие кэширования уже играет против движка, т.к. древняя страница всё равно больше никому не понадобится потом, а время на её кэширование потратится.
Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов. В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД). А как это сделать на уровне сервера? Apache? Вот в чём вопрос. И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
>>> Итого, решением проблемы могла бы стать возможность банить айпишник, с которого на протяжении, к примеру, двух минут приходит 20-40 запросов.
Ровно этот похдод проверяли пару месяцев назад. Кончилось тем, что нормальные пользователи начали пищать, а качальщикам - пофигу. Они и по 10 запросов вынесут сервер - разве что будет вместо одноно качальщика 2+
Я забил в поиск строку, открыл первые пару листов результатов - типичная операция при работе с форумом. 38 запросов за 30 секунд...
А ведь запросто несколько пользователей могут оказатсья за одним IP, а качальщик будет просто каждые 5 минут устанавливать новое подключение, получать от провайдера новый адрес или менять прокси.
>>> В движке организовать такое - потребует слишком больших вычислительных мощностей (постоянно анализировать десятки тысяч айпишников на предмет их присутствия в заданном временном диапазоне - неподъёмная нагрузка для БД).
Во-первых, не постоянно, а только для страниц пролетевших мимо кэша, для 95% случае (или какова там у нас эффективность кэша) никаких дополнительных проверок не надо.
Во-вторых, "десятки тысяч записей" - жупел. Один дополнительный SELECT по _идексированой_ таблице это вообще не проблема, даже если там и в самом деле несколько десятков тысяч записей - благо таблицу можно периодически чистить.
>>> А как это сделать на уровне сервера? Apache? Вот в чём вопрос.
См. выше. Делал я зимой такое, пострадали невиновные. И я выше написал почему.
Веб-сервер _не_знает_ про кэшированые страницы, а это _надо_ для принятия решения.
>>> И пока решение видится лишь "экстенсивным" - наращивание мощностей самого железа.
Это не "пока", это вообще единственное решение.
Пиковая загрузка - не так страшна, в дневное время при работающем мониторинге нет проблем отстреливать качальщиков руками. Можно привлечь модераторов и т.п.
А вот со средним уровнем нагрузки сделать ничего нельзя. Движок будет обрастать фичами и становиться все тяжелее, количество посетителей будет увеличиваться - в конце концов ромба загнется под собственным весом и без всяких качальщиков.
Среднее количество просмотров страниц на одного посетителя очень хорошо кореллирует с нагрузкой - когда сервер начинает подтормаживать и отдавать страницы медленнее чем привык пользователь - человек просто уходит.
У нас три проблемы:
1) Корректно интегрировать отстрел качальщиков в движок (плагин или типа того) не получается и не факт что вообще возможно внедриться в потрха друпала на таком уровне.
2) Изменение кода движка для отстрела качальщиков повлечет за собой невозможность обновления движка.
3) Ресурсов на поддержку "модифицированой" версии движка у нас нет. Если продолжать "ломать" движок - придется переписывать каждую новую версию друпала под себя - мы потеряем возможность обновления и установки секьюрити-фкисов от производителя. Дефейс и кража персональных данных через свежиу уязвимости Drupal'а - вполне вероятный вариант при таком развитии событий.
ex-K9
Размер кеша - ограничивается собссно движком, или же объемом диска сервера?
Да и с модификацией движка - нет функции вести логи промахов мимо кеша, с сохранением ИП? Если же делать модификацию - то никто не мешает внедрить свой код в функцию собссно генерации странички в случае ее отсутствия в кеше, и юзать глобальные переменные движка, а то и переменные ПХП... ИМХО при переходе от версии к версии переменные особо меняться не должны, а переносить - патчем...
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
>>> Размер кеша - ограничивается собссно движком, или же объемом диска сервера?
При приближении эффективности кэша к 100% объем БД будет возрастать нелинейно - тупиковый путь развития который опять же потребует железа.
>>> Да и с модификацией движка - нет функции вести логи промахов мимо кеша, с сохранением ИП? Если же делать модификацию - то никто не мешает внедрить свой код в функцию собссно генерации странички в случае ее отсутствия в кеше, и юзать глобальные переменные движка, а то и переменные ПХП... ИМХО при переходе от версии к версии переменные особо меняться не должны, а переносить - патчем...
Есть желающие заняться реализацией этих идей во временном промежутке от полугода и далее?
Выше шла речь именно об этом: у нас нет человеческих ресурсов на нормальную поддержку своего форка. Нехватает человеко-часов, знаний, навыков и т.п.
Если бы здесь был форум веб-программистов - было бы вероятно иначе. Но тут ремонтники. А ромба как веб-приложение давно уже миновала уровень наколенной поделки в потрохах которой может разобраться любой энтузиаст смежной сферы за пару вечеров колупания методом научного тыка.
ex-K9
Насчет эффективности кеша - оно-то понятно... Интересовало, чем именно вызван лимит - возрастающей нагрузкой на базу/апач при запросах к большому кешу либо же все упирается в дисковое пространство...
Попробую качнуть движок и глянуть ему в код...
Уважаемые коллеги, в переписке с нашими англоязычными партнерами помните: whether - который, weather - погода, wether - кастрированый баран!
У некоторых людей торс - это просто разветвитель, позволяющий подключить руки и голову к заднице.
Отправить комментарий