Параллельные проблемы с производительностью веб-запросов

Я работаю над новым сервисом для запуска QA для нескольких веб-ресурсов наших компаний и столкнулся с интересной проблемой параллелизма в сети. Чтобы повысить производительность, я использую TPL для создания HttpWebRequests на основе большой коллекции URL-адресов, чтобы они могли выполняться параллельно; однако я не могу найти узкое место в этом процессе.

Мои наблюдения на данный момент:

• Я могу получить максимум около 25 -30 параллельных потоков через TPL
• . ЦП никогда не выходит из строя 5 -6% для службы (, работающей на 1 -4 ядрах, с H/T и без)
• Использование сетевой карты никогда не прерывается 2 -3%
• Общий сетевой трафик, похоже, не пострадал (, другие пользователи не жалуются,одновременные тесты скорости не показывают большого эффекта)
• Скорость не сильно отличается между работой в нашей офисной сети (15 Мбит/с )или в нашем центре обработки данных (100+ Мбит/с )
• . Я получаю небольшой прирост производительности за счет одновременной загрузки с нескольких хостов, а не множества страниц с одного хоста.

Возможные болевые точки:

• CPU (количество ядер или аппаратных потоков)
• Сетевая карта
• Максимально допустимое количество одновременных запросов HttpWebRequests
• ЛВС
• Глобальная сеть
• Маршрутизатор/коммутатор/балансировщик нагрузки

Итак, вопрос:

Очевидно, что теперь есть способ загрузить весь Интернет за считанные минуты, но мне интересно узнать, где находится узкое место в подобном сценарии и что можно сделать, чтобы его преодолеть.

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