Здравствуйте, yniker, Вы писали:

Y>Спасибо всем за ответы, удалось решить проблему почему DownloadStringCompleted
Y>не вызывается, все очень просто, нет timeout для асинхронных операций, их должен писать разработчик. Поэтому весит вечно, думают тут благодаря антивирусу или firewall на моем ПК ибо на других все отлично.


VN>>Все равно, задача для каждого клиента не будет длиться меньше, чем время всех (логически) последовательных закачек и анализа, нужных конкретному клиенту. Тут чудес не бывает, читай закон Амдала.

Y>Амдала для вычислительных опрераций, IO операции не совсем то.

Ага, но и они не позволят тебе базироваться на результатах IO прежде, чем это IO не закончится. Ну нет такой машины времени...
Кроме того, пусть это просто сброс данных на диск, но если это единственная seq операция, то время сброса данных (результатов) будет учитываться...

VN>>задача для каждого клиента не будет длиться меньше, чем время всех (логически) последовательных закачек и анализа, нужных конкретному клиенту
Y>Это естественно.


VN>>Если у тебя 10000 клиентов, то парадигма клиент-поток уже давно не работает, так как ты думаешь, что используют в этих случаях?

Y>P-C + асинхронность, только P- равное "примерно" кол-во процессоров в системе?
Не P- а -C. Продюсеры — это не потоки! Это сущности, каждый консумер может выступить в роли продюсера, запихнув в очередь порцию данных для другого консумера. Вот они уже являются активной единицей, в отличии от продюсеров, в качестве которых может выступать кто угодно.

По сути расчитывать можно так:
-> количество ядер = количество консумеров, которые занимаются анализом
+ количество ядер * 10 (или 5) = количество консумеров, которые занимаются IO

Балансировать можно по принципу уменьшения количесва консумеров, пока их в очереди (ждут задачу) больше одного.