После выполнения HttpWebRequests в течение некоторого времени результат начинает истекать

Question

У меня есть приложение, которое пауков веб-сайтов для информации. Кажется, что после 20-45 минут создания HttpWebRequests куча из них возвращает таймауты. Одна вещь, которую мы делаем, это прикрепляем анонимную функцию BindIPDelegate, чтобы назначить запросу конкретный IP, так как мы проходим около 150 IP.

Я настраиваю объект HttpWebRequest со следующими настройками ..

• Настройка User-Agent
• Установка для Keep-Alive значения false, чтобы IP-адрес не использовался повторно
• Настройка времени на 60000 (60 секунд)
• Установка ReadWriteTimeout на 60000 (60 секунд)
• Установка прокси в ноль
• Настройка Принять к /
• Настройка CookieContainer для нового CookieContainer
• Настройка Piplined на true
• Настройка автоматической декомпрессии для Deflate & GZIP

Приложение использует .NET 4.0 и работает на Windows Server 2008 R2.

Это определенно кажется чем-то связанным с приложением / TCP / .NET, потому что, если я перезапущу приложение, оно снова будет работать нормально. Кроме того, кажется, более или менее похоже, что те, кто отключился, просто стоят в очереди, ожидая на локальном порту или что-то в этом роде.

Есть идеи?

Answer 1

Вы не много говорите о коде, который фактически используете для выполнения запросов, но, в любом случае, вот мои догадки:

1. Вы используете BeginGetResponse()/EndGetResponse() с обратным вызовом иобратный вызов занимает слишком много времени для завершения (или блокирует!).Это может вызвать тупик в пуле потоков, если вы отправляете много запросов за короткий промежуток времени.

2. Поскольку вы не используете соединения повторно и, опять же, если запросы происходяточень быстрый и безостановочный, у вас могут не хватить сокетов (в прошлый раз, когда я пытался, ~ 3k на интерфейс в Windows).Если установка KeepAlive в значение true устраняет вашу проблему, вот она.

3. Вы не вызываете Dispose()/Close() в запросе HttpWebRequest, HttpWebResponse или в потоке, полученном из ответа.Это может работать немного, пока вы не достигнете предела 2 (из документов MSDN) или 6 (файл конфигурации по умолчанию) в настройках конфигурации приложения для ( system.net / connectionManagement / add [address = "*"), maxconnection = "6"] ).Простой способ проверить, является ли это проблемой, - установить ограничение на 1 и посмотреть, возникает ли проблема раньше, чем раньше.

Кстати, для KeepAlive установлено значениеложь и Конвейер к истине не имеет смысла.

Answer 2

Я думаю, это связано с проблемами, связанными с ThreadPool.

Answer 3

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

  <system.net>
    <defaultProxy enabled="false">
    </defaultProxy>
    <connectionManagement>
      <remove address="*"/>
      <add address="*" maxconnection="1000" />
    </connectionManagement>
  </system.net>

Edit: Я думаю, что тег defaultProxy былдействительно, очень важный тег.

Answer 4

проще показать пример того, что я имел в виду в комментариях, а не мою собственную работу, но ребята из Microsoft делают такую ​​приятную работу, что я передаю вам ссылку.

http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.begingetrequeststream.aspx

Если вы делаете тяжелый ввод через http, я всегда советую посмотреть на механизмы обратного вызова.

Также убедитесь, что вы закрыли эти проклятые объекты httpWebRequest.Оберните все в пузырчатую пластиковую оболочку, используя свободно выраженные операторы использования.

многопоточные операции: по умолчанию установлено 2 соединения на хост-соединение.
Этот параметр можно изменить.Если используется максимальное количество подключений, то операции HttpWebRequest (запрос / ответ) будут поставлены в очередь до тех пор, пока не будет доступен слот подключения.

статья, с которой я столкнулся, ссылаясь на веб-сервисы, также может повлиять на вашу проблему, так какпричины очень похожи, вот ссылка:

http://support.microsoft.com/kb/821268

Answer 5

Я предполагаю, что, возможно, не все объекты расположены правильно, а некоторые порты TCP остаются открытыми. Попробуйте посмотреть, какие объекты реализуют IDisposable. По крайней мере, результаты из GetResponse и GetResponseStream являются IDisposables и должны быть правильно расположены.

Answer 6

Может ли быть IDS на удаленном конце, думая, что вы злоумышленник и блокирует вас?