Здравствуйте, Аноним, Вы писали:
А>Кстати, если проблема воспроизводится под отладчиком, то можно приостановить выполнение и посмотреть на активные потоки и их стэк трейсы. А>По крайней мере понятно будет, завис ли клиент или потерялся результат.
Да, действительно исключение есть. какое-то внутренное.
"Заданного параметра реестра не существует." думаю прокси идет проверка.
Но только что-то проверил на третей уже машине, все работает отлично работает с учетом и этого исключения.
Но проблема остается, на моей машине значит и у пользователей она будет
Здравствуйте, Аноним, Вы писали:
А>Кстати, если проблема воспроизводится под отладчиком, то можно приостановить выполнение и посмотреть на активные потоки и их стэк трейсы. А>По крайней мере понятно будет, завис ли клиент или потерялся результат.
Здравствуйте, vvlad.net, Вы писали:
VN>Здравствуйте, yniker, Вы писали:
Y>>Тоже рассматриваю вариант, но пока не могу его применить логически для своей задачи. Не могу толком понять применимость.
VN>Уже понятно.
VN>разбей твою задачу на подзадачи: VN>- вместо скачать-проанализировать-скачать-сохранить VN>- станет:
VN>1. producer pushes download task to queue VN>2. consumer takes the task, downloads VN>3. consumer becomes producer — pushes downloaded result to queue VN>4. consumer (another one maybe) — takes the downloaded result, analyses it VN>5. consumer becomes producer — pushes download task (analyse result) to queue VN>6. consumer takes the task to download, pushes thre sult to queue VN>7. consumer takes the result, saves it to db
VN>that's all.
VN>Количество консумеров — количество потоков, не будет простоя. VN>В самих консумерах юзай пока синхронный вариант, тебе опыта не хватит заюзать асинхронный, VN>да и не особо это и критично для твоей задачи.
Проанализировав ваш ответ (патерн), это не правильное решение.
Что даст этот патерн.
Создаем 1 поток. который подает данные.
Создаем 1000 потоков которые читают данные с первого потока и делают загрузку, анализ.
И совсем не критично, ну подумаешь 1гиг памяти для потоков выделится просто так, процессор будет нагружен переключением потоков, и самой интересное что 99% вообще эти потоки ничего делать не будут, а просто синхронно ждать.
А Microsoft путь и дальше придумывает свои Task, ThreadPool, await и асинхронные операции. Мы будем плодить потоки.
Здравствуйте, yniker, Вы писали:
Y>Здравствуйте, vvlad.net, Вы писали:
VN>>Здравствуйте, yniker, Вы писали:
Y>>>Тоже рассматриваю вариант, но пока не могу его применить логически для своей задачи. Не могу толком понять применимость.
VN>>Уже понятно.
VN>>разбей твою задачу на подзадачи: VN>>- вместо скачать-проанализировать-скачать-сохранить VN>>- станет:
VN>>1. producer pushes download task to queue VN>>2. consumer takes the task, downloads VN>>3. consumer becomes producer — pushes downloaded result to queue VN>>4. consumer (another one maybe) — takes the downloaded result, analyses it VN>>5. consumer becomes producer — pushes download task (analyse result) to queue VN>>6. consumer takes the task to download, pushes thre sult to queue VN>>7. consumer takes the result, saves it to db
VN>>that's all.
VN>>Количество консумеров — количество потоков, не будет простоя. VN>>В самих консумерах юзай пока синхронный вариант, тебе опыта не хватит заюзать асинхронный, VN>>да и не особо это и критично для твоей задачи.
Y>Проанализировав ваш ответ (патерн), это не правильное решение. Y>Что даст этот патерн. Y>Создаем 1 поток. который подает данные. Y>Создаем 1000 потоков которые читают данные с первого потока и делают загрузку, анализ. Y>И совсем не критично, ну подумаешь 1гиг памяти для потоков выделится просто так, процессор будет нагружен переключением потоков, и самой интересное что 99% вообще эти потоки ничего делать не будут, а просто синхронно ждать. Y>А Microsoft путь и дальше придумывает свои Task, ThreadPool, await и асинхронные операции. Мы будем плодить потоки.
Мда, парниша. А как ты хочешь делать одновременные загрузки и анализ? в одном потоке???
Почитай про многопоточность и IO. Особенно про последнее. Я тебе в письме отписывал — пока работает IO операция, спит поток, который ее вызвал, зато активируется другой, который в этот момент делает анализ чего-либо. Если тебе стремно создавать 1000 потоков (по метру памяти на каждый), то тогда тебе надо поискать форумы по эрлангу.
Я, в принципе, мог бы сделать вариант, когда потоки не ждут (запустили IO, ушли делать другие дела), это сэкономит нам количество потоков (но время выполнения останется практически тем-же). Да и то, что я прислал — уже для такого подходит.
VN>Мда, парниша. А как ты хочешь делать одновременные загрузки и анализ? в одном потоке???
VN>Почитай про многопоточность и IO. Особенно про последнее. Я тебе в письме отписывал — пока работает IO операция, спит поток, который ее вызвал, зато активируется другой, который в этот момент делает анализ чего-либо. Если тебе стремно создавать 1000 потоков (по метру памяти на каждый), то тогда тебе надо поискать форумы по эрлангу. VN>Я, в принципе, мог бы сделать вариант, когда потоки не ждут (запустили IO, ушли делать другие дела), это сэкономит нам количество потоков (но время выполнения останется практически тем-же). Да и то, что я прислал — уже для такого подходит.
Не получил от Вас письма, буду благодарен если еще раз перешлете, (в спаме тоже нет.)
Спасибо. y n i k e r @ g m a i l . c o m
VN>>Мда, парниша. А как ты хочешь делать одновременные загрузки и анализ? в одном потоке???
VN>>Почитай про многопоточность и IO. Особенно про последнее. Я тебе в письме отписывал — пока работает IO операция, спит поток, который ее вызвал, зато активируется другой, который в этот момент делает анализ чего-либо. Если тебе стремно создавать 1000 потоков (по метру памяти на каждый), то тогда тебе надо поискать форумы по эрлангу. VN>>Я, в принципе, мог бы сделать вариант, когда потоки не ждут (запустили IO, ушли делать другие дела), это сэкономит нам количество потоков (но время выполнения останется практически тем-же). Да и то, что я прислал — уже для такого подходит.
Y>Не получил от Вас письма, буду благодарен если еще раз перешлете, (в спаме тоже нет.) Y>Спасибо. y n i k e r @ g m a i l . c o m
Здравствуйте, vvlad.net, Вы писали:
VN>Здравствуйте, yniker, Вы писали:
VN>>>Мда, парниша. А как ты хочешь делать одновременные загрузки и анализ? в одном потоке???
VN>>>Почитай про многопоточность и IO. Особенно про последнее. Я тебе в письме отписывал — пока работает IO операция, спит поток, который ее вызвал, зато активируется другой, который в этот момент делает анализ чего-либо. Если тебе стремно создавать 1000 потоков (по метру памяти на каждый), то тогда тебе надо поискать форумы по эрлангу. VN>>>Я, в принципе, мог бы сделать вариант, когда потоки не ждут (запустили IO, ушли делать другие дела), это сэкономит нам количество потоков (но время выполнения останется практически тем-же). Да и то, что я прислал — уже для такого подходит.
Y>>Не получил от Вас письма, буду благодарен если еще раз перешлете, (в спаме тоже нет.) Y>>Спасибо. y n i k e r @ g m a i l . c o m
VN>Ок, перешлю.
Спасибо за код, но это не то.
Да хороший красивый патерн, возможно приятней чем
(Создаем 1 поток. который подает данные.
Создаем 1000 потоков которые читают данные с первого потока и делают загрузку, анализ.)
Там тоже создаются потоки, ну по крайней мере в той реализации.
Так я сразу приведу пример, чтобы по сто раз не возвращаться к патерну и к куче потоков.
Я не спорю несколько или разумное кол-во потоков все равно будет. В идеале равное кол-ву процесоров.
У меня есть сервер на 10000 клиентов, с 32 ОС. Всем надо работать "паралельно, одновременно".
1. ОС не даст создать 10000 потоков.
2. Работать не будет? БУДЕТ! и всего в нескольких потоках.
Да и поможет здесь не форумы по по эрлангу, а асинхронная работа.
Чудеса? Нет.
Советую вам прочитать главу по работе с IO и Потоками, Рихтера CLR via C# 4.0
Здравствуйте, yniker, Вы писали:
Y>У меня есть сервер на 10000 клиентов, с 32 ОС. Всем надо работать "паралельно, одновременно". Y>1. ОС не даст создать 10000 потоков. Y>2. Работать не будет? БУДЕТ! и всего в нескольких потоках. Y>Да и поможет здесь не форумы по по эрлангу, а асинхронная работа. Y>Чудеса? Нет. Y>Советую вам прочитать главу по работе с IO и Потоками, Рихтера CLR via C# 4.0
Ну а я что говорил? разве я предлагал по нескольку потоков на клиента?
Ты же как партизан молчишь, подробностей не даешь совсем.
А что такое асинхронная работа, ты сам знаешь? а что с P-C это и можно организовать (количество и типы консумеров — на усмотрение разработчика).
Все равно, задача для каждого клиента не будет длиться меньше, чем время всех (логически) последовательных закачек и анализа, нужных конкретному клиенту. Тут чудес не бывает, читай закон Амдала.
Если у тебя 10000 клиентов, то парадигма клиент-поток уже давно не работает, так как ты думаешь, что используют в этих случаях?
Спасибо всем за ответы, удалось решить проблему почему DownloadStringCompleted
не вызывается, все очень просто, нет timeout для асинхронных операций, их должен писать разработчик. Поэтому весит вечно, думают тут благодаря антивирусу или firewall на моем ПК ибо на других все отлично.
VN>Все равно, задача для каждого клиента не будет длиться меньше, чем время всех (логически) последовательных закачек и анализа, нужных конкретному клиенту. Тут чудес не бывает, читай закон Амдала.
Амдала для вычислительных опрераций, IO операции не совсем то.
VN>задача для каждого клиента не будет длиться меньше, чем время всех (логически) последовательных закачек и анализа, нужных конкретному клиенту
Это естественно.
VN>Если у тебя 10000 клиентов, то парадигма клиент-поток уже давно не работает, так как ты думаешь, что используют в этих случаях?
P-C + асинхронность, только P- равное "примерно" кол-во процессоров в системе?
Здравствуйте, 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
Балансировать можно по принципу уменьшения количесва консумеров, пока их в очереди (ждут задачу) больше одного.
