Есть ли способ выполнить метод несколько раз, кроме управления соединениями / потоками? (.СЕТЬ) - PullRequest
2 голосов
/ 27 января 2009
  1. У меня есть метод, который использует соединение (например, метод, который загружает страницу).
  2. Я должен выполнить этот метод несколько раз (например, загрузить 1000 страниц).
  3. Синхронный и последовательный процесс занимает много времени.
  4. У меня ограниченные ресурсы (максимум 8 потоков и / или 50 одновременных подключений)
  5. Я хочу использовать все ресурсы для его ускорения.
  6. Я знаю, что распараллеливание (PLINQ, Parallel Extensions и т. Д.) Может решить проблему, но я уже пробовал это, и этот подход не работает из-за ограниченных ресурсов.
  7. Я не хочу изобретать колесо, которое распараллеливает задачи такого рода при управлении ресурсами, кто-то должен был сделать это раньше и должен предоставить библиотеку / учебник для этого.

Может кто-нибудь помочь?

Обновление Все становится намного сложнее, когда вы начинаете смешивать асинхронные вызовы с распараллеливанием для максимальной производительности. Это реализовано на нескольких загрузчиках, таких как загрузчик Firefox, он получает 2 загрузки одновременно, а когда одна из них завершена, он получает следующий файл и так далее. Может быть, это кажется очень простым для реализации, но когда я реализовал его, у меня были и остаются проблемы с тем, чтобы сделать его универсальным (полезным для WebRequest и DbCommand) и иметь дело с проблемами (например, тайм-ауты)

Bounty Hunters Награда будет предоставлена ​​первой, которая связывает надежную и бесплатную ($$) библиотеку .NET, которая предоставляет простой способ C # для распараллеливания асинхронных задач как HttpWebRequests.BegingetResponse и SqlCommand. BeginExecuteNonQuery. Распараллеливание не должно ждать завершения N задач, чтобы затем запустить следующую N, но оно должно начать новую задачу, как только одна из N начальных завершится. Метод должен был обеспечить обработку тайм-аута.

Ответы [ 11 ]

1 голос
/ 01 февраля 2009

Асинхронные методы WebRequest могут показаться медлительными, поскольку они блокируются при выполнении поиска DNS, а затем переключаются на асинхронное поведение. Пройдя по этому пути самому, кажется неэффективным раскручивать восемь потоков для подачи запросов в API, который уже раскручивает потоки для выполнения большей части работы. Вы могли бы пересмотреть некоторые из своих подходов с учетом этого недостатка асинхронного API WebRequest. Наше решение в конечном итоге включало использование синхронного API, каждый в своем потоке. Мне было бы интересно, чтобы кто-нибудь прокомментировал правильность этого подхода.

...