Task vs ThreadPool vs new Thread?

Question

[unknown3]

Стоит задача, обработать 100+ долговременных операций ( допустим каждая занимает по 10 сек). Естественно обрабатывать нужно асинхронно, все одновременно. Ну 100 штук обработали и миллион еще на походе если что...
Так вот как сделать это более правильно и более быстро?
Ограничение: .NET Framework 4.0

Написал пример 3х реализаций

for (int i = 0; i < 100; i++) {
                int j = i;
                Task t = new Task(() => {
                    Console.WriteLine("RUN "+j);
                    Thread.Sleep(10000);
                    Console.WriteLine("end " + j);
                });
                t.Start();

                //ИЛИ
                ThreadPool.QueueUserWorkItem(state => {
                    Console.WriteLine("RUN " + j);
                    Thread.Sleep(10000);
                    Console.WriteLine("end " + j);
                });
                //ИЛИ
                Thread t = new Thread(() =>
                {
                    Console.WriteLine("RUN " + j);
                    Thread.Sleep(10000);
                    Console.WriteLine("end " + j);
                });
                t.Start();
            }

Если использовать Task и ThreadPool, то уже на 20й таске все резко замедляется и идет очень медленно, создание каждой новой таски или тредпула 1-3 сек ( даже если указали что ThreadPool.SetMaxThreads(100, 100);)
Если использовать new Thread, то всё работает как нужно. Мгновенно всё создается и выполняется одновременно и завершается +- одновременно.
НО! Как везде утверждают что таски и тредпулы быстрее, лучше использовать их. Что new thread это долгая и дорогостоящая операция, но тест показывает что всё как раз на оборот.
Так какой способ вы бы использовали?

Comments

[edward_freedom]

зачем в таске поток останавливать? Thread.Sleep

[unknown3]

edward_freedom, эмулируем выполнение каких-то действий, в реале это пересылка данных 100+ сокетам, у некоторых клиентов очень печальная скорость инета.

[edward_freedom]

unknown3, в таске задержка эмулируется await Task.Delay, а Thread.Sleep в потоке

[unknown3]

edward_freedom, ну await это слишком современно для .net 4.0 ну допустим я напишу так

Task t = new Task(() => {
                    Console.WriteLine("RUN "+j);
                    Task.Delay(10000).Wait();
                    Console.WriteLine("end " + j);
                });
                t.Start();

Ну сути дела это не меняет, первые 10 тасков пролетают мнгновенно. С 11й начинает каждую секунду выполнять.

[Василий Банников]

unknown3, раз это сокеты, то используй таски и async-await в .net 4 они уже есть

[Василий Банников]

unknown3, только не new Task, а Task.Run. и await не забывай.
И ConfigureAwait(false)

[unknown3]

Василий Банников,

Async/Await have been introduced with C# 5.0 and .NET Framework 4.5

Я же говорю таски медленные. Вот я создаю сразу 100 тасков, и запускаю их. 10 из них мгновенно начинают выполняться, а остальные каждая через 1-3 сек.
Пока они все выполнятся у меня или клиенты по таймауту отвалятся или клиенты пришлют еще запросов на которые нужно дать еще ответы, а это значит нужно наплодить еще тасков, а у меня еще прошлые не выполнились...
Ну наверно нужно использовать new Thread, почему нет?

[unknown3]

Василий Банников,

только не new Task, а Task.Run. и await не забывай.
И ConfigureAwait(false)

Всеравно это медленно, первые 10-15 задач быстро начинают выполнятся, далее медленно.

[Василий Банников]

unknown3, просто увеличь стартовое количество потоков в пуле.

[none7]

Нужно понимать, что Thread это вытесняющая многозадачность, а Task кооперативная. То есть, при выполнении Task.Delay задача будет исполнена не раньше чем истечёт указанное время И не раньше, чем один из потоков ThreadPool освободится. Очевидно, что при этом оно может давать неадекватные задержки. Но в общем целом таски дешевле, так как не нужно обращаться к ядру ОС, выделять на каждый поток стек и т.д. Просто число потоков должно соответствовать числу ядер + числу задач выполняемых долго или синхронно ожидающих ответа от ядра, например из за Mutex.WaitOne() или File.Open().

Answer 1

[Илья]

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

2) Таски используют пул потоков, поэтому особой разницы между ThreadPool.QueueUserWorkItem и запуском Таски нет.

3) Что Thread.Sleep(10000) что Task.Delay(10000).Wait() - это блокирующая операция, которая приводит к тому что называют thread pool starvation. То есть поток не имеет возможности вернуться в пул и переиспользоваться. У пула потоков есть задержка на ввод нового потока в работу, поэтому у вас все и тормозит.

Вывод в том, что вы некорректно готовите асинхронность. Во всех случаях вы блокируете потоки и количество потоков у вас во всех случаях примерно одинаковое задействуется. Если вы ограничены 4.0, то скорее всего, лучшим вариантом будет старая модель асинхронности .net
https://docs.microsoft.com/en-us/dotnet/standard/a...
У сокетов есть соответствующие методы

Comments

[Илья]

Дополнительное чтиво про "голодание" пула потоков
https://docs.microsoft.com/en-us/archive/blogs/van...

[unknown3]

Илья, Ладн крч, понятно. Ну недогруза проца, точно не наблюдается. Он в проблемные моменты грузит на все 100%, тоесть он просто физически не может обработать все запросы. У меня там все построено на таксках, вот я думал мож на new Thread переделать и поможет....

Хотя под каждый сокет(каждого клиента) при подключении создается отдельный thread, который висит и ждет сообщений от клиента (ведь using (var stream = new NetworkStream(socket)) блокирует поток). Ну соотвественно на 100+ клиентов, которые там постоянно висят создано 100+ тредов. Ну с этими проблем нет.

Крч выхода 3, которые я вижу. Первый апгрейд железа. Второй уменьшение количества постоянно подключенных клиентов, хотя это навер невозможно. И третий, то что нужно было сделать с самого начала и предусмотреть этот момент, больше кешей у клиентов, меньше запросов, убрать с сервера ORM ибо еще тот тормоз, ну удобно же!

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

Потому-что основная проблема как мне кажется, есть 100 клиентов у 5 из них херовый интернет. Когда я создаю таску и в цикле пытаюсь отправить всем сообщений, когда итерация доходит до клиентов с херовым интернетом, на них тратится очень много времени и все эти таски висят. А если у каждого клиента будет поток который занимается отправкой сообщений именно ему, то всем клиентам с быстрым интернетом сообщения будут доставлятся мгновенно, а тем у которых херовый интернет, пускай висят стеки сообщений, когда-то они да обработаются, главное они не будут тормозить остальных. Ну это так мысли...

[Илья]

unknown3,

Ну недогруза проца, точно не наблюдается. Он в проблемные моменты грузит на все 100%

Скорее всего это происходит из-за того что ваш сервер на самом деле не асинхронный. А процессор грузится не работой а блокировками.

Крч выхода 3, которые я вижу.

Вам нужно сначала поработать с профиллировщиком, и посмотреть на что у вас расходуются ресурсы процессора, а после думать о решениях. Пока вы гадаете на кофейной гуще.

апгрейд железа

По моему опыту, виртуалка с 1 ядром и 1.5Гб памяти нормально справляется с несколькими тысячами сокетов + SSL. Если правильно все сделать.

Рекомендую ознакомиться с этой докой
https://docs.microsoft.com/en-us/dotnet/framework/...
Кажется вам это подойдет

[unknown3]

Илья,
Железо intel pentium e2180 2 гига памяти.

Каким профилировщиком можно продиагностировать C# приложение на windows server 2003?

Ну по факту все эти BeginReceive, BeginSend делают всё тоже самое. Они же где-то также создают блокирующий поток, ждут пока чёто придет, чёто пришло они дёрнули ваш колбэк. Ну или если отправляем, опять создают какую нибудь отдельную таску и отправляют и дергают колбэк если нужно, что это отправлено... Мне кажется это еще лишний врапер над всем этим, который только замедлит работу

[Илья]

Каким профилировщиком можно продиагностировать C# приложение на windows server 2003?

perfview или dottrace

Мне кажется это еще лишний врапер над всем этим, который только замедлит работу

Ну вот вы опять гадаете, если бы эти операции были блокирующими, то этот подход бы не назывался Asynchronous Programming Model.
Внутри этих методов используются примитивы синхронизации уровня ядра ОС. Планировщик ОС, когда доходит до потока и видит такую блокировку, то сразу пропускает его, не выделяет ему квант времени, поэтому процессор не загружается.