Как определить разумное количество одновременных запросов, которые я могу безопасно выполнять на чьем-то сервере?

Я сканирую некоторые данные из Интернета, потому что там нет API. К сожалению, это довольно много данных с нескольких разных сайтов, и я быстро понял, что не могу просто сделать тысячи запросов на один и тот же сайт за короткое время... Я хочу получить данные как можно быстрее, но я не могу не хочу вызывать DOS-атаку :)

Проблема в том, что каждый сервер имеет разные возможности, и я не знаю их заранее. Сайты принадлежат моим клиентам, поэтому я намерен предотвратить любые возможные простои, вызванные моим скриптом. Так что никакой политики типа "сначала я попробую миллион запросов, а если не получится, попробую полмиллиона, а если не получится..." :)

Есть ли лучшая практика для этого? Откуда сканер Google знает, сколько запросов он может сделать за одно и то же время на один и тот же сайт? Возможно, они «тасуют свой плейлист», чтобы не было столько одновременных запросов к одному сайту. Могу ли я как-то обнаружить это через HTTP? Дождаться одиночного запроса, посчитать время отклика, примерно угадать, насколько сбалансирован сервер, а потом каким-то образом составить максимальное количество одновременных запросов?

Я использую скрипт Python, но это не имеет большого значения для ответа — просто чтобы вы знали, на каком языке я бы предпочел ваши потенциальные фрагменты кода.


http concurrency web-crawler denial-of-service
person Honza Javorek    schedule 07.09.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Google Spider чертовски умен. На моем маленьком сайте он бьет меня со скоростью 1 страница в минуту с точностью до секунды. У них, очевидно, есть очередь страниц, которая заполняется с учетом времени и сайтов. Я также задаюсь вопросом, достаточно ли они умны, чтобы не задействовать несколько доменов на одном сервере, поэтому некоторое распознавание диапазонов IP-адресов, а также URL-адресов.

Отделение работы по постановке в очередь URL-адресов для сканирования в определенное время от собственно работы паука было бы хорошей архитектурой для любого паука. Все ваши пауки могут использовать метод urlToSpiderService.getNextUrl(), который будет блокировать (при необходимости), если следующий URL-адрес не будет просканирован.

Я считаю, что Google смотрит на количество страниц на сайте, чтобы определить скорость паука. Чем больше страниц вы обновляете в данный момент времени, тем быстрее они должны попасть на этот конкретный сервер. Вы, безусловно, должны быть в состоянии использовать это в качестве метрики, хотя до того, как вы выполните начальное сканирование, это будет трудно определить.

Вы можете начинать с одной страницы каждую минуту, а затем, по мере увеличения количества страниц, подлежащих поиску для определенного сайта, вы будете уменьшать задержку. Потребуется какая-то функция, подобная следующей:

 public Period delayBetweenPages(String domain) {
     take the number of pages in the to-do queue for the domain
     divide by the overall refresh period that you want to complete in
     if more than a minute then just return a minute
     if less than some minimum then just return the minimum
 }

Могу ли я как-то обнаружить это через HTTP?

С современным интернетом я не понимаю, как можно. Конечно, если сервер возвращается через пару секунд или возвращает 500 ошибок, то вы должны регулировать слишком назад, но типичное соединение и загрузка в наши дни для большого процента серверов занимают доли секунды, и я Я не уверен, что можно многому научиться из какой-либо статистики в этой области.

person Gray    schedule 07.09.2012
comment
Спасибо за очень полезный ответ! Я добавляю эту ссылку только по соответствующей теме: en.wikipedia.org/wiki/ Вероятно, немногие веб-сайты поддерживают его, но если они это сделают, сканер может уважать его. - person Honza Javorek; 10.09.2012
comment
К сожалению, держу пари, менее 5% веб-сайтов публикуют это. Я знаю, например, что мой домашний и мой корпоративный веб-сайт — нет. - person Gray; 10.09.2012
comment
Конечно, я услышал об этом впервые в жизни. Тем не менее, все равно интересно узнать, что что-то подобное существует. - person Honza Javorek; 10.09.2012