Несколько одновременных потоков с проблемой веб-запросов

Question

Я строю довольно сложную параллельную систему и наткнулся на странную проблему. Я постараюсь быть простым.

1. У меня есть консольное приложение с одним экземпляром на .net core 2.1
2. У меня есть один экземпляр HttpClient
3. Я установил следующие параметры: System.Net.ServicePointManager.DefaultConnectionLimit = int.MaxValue; System.Net.ServicePointManager.ReusePort = true; HttpClient.DefaultRequestHeaders.ConnectionClose = true; HttpClient.SetBearerToken (SOME_TOKEN);
4. У меня есть поток (A) , который постоянно создает до 30 новых параллельных потоков с одним запросом HTTP GET внутри, используя ThreadPool / new Thread () (пробовал оба) и помещает результаты в переменную ConcurrentQueue.
5. У меня есть другой поток (B) , который читает из очереди и постоянно создает до 30 новых параллельных потоков с одним запросом HTTP POST внутри.

Проблема в том, что я получаю следующий рабочий процесс:

1. Поток A работает хорошо, отправляя очередь с результатами. Все темы работают нормально.
2. Поток B начинает создавать дочерние потоки для POST после запуска потока A.
3. Поток A завершает свою работу, все потоки завершаются. На этом этапе все потоки, созданные потоком B, висят на клиенте await. Метод PostAsync () .
4. Приложение зависает примерно на 10 секунд.
5. Журнал VS показывает несколько Поток 0x35e0 завершился с кодом 0 (0x0). Сообщения о том, что ранее использовавшиеся потоки освобождаются. Почему так долго?!
6. Приложение зависает на 20 секунд
7. Первые потоки, созданные потоком B, начинают отказывать, а все остальные потоки B начинают нормально работать.

Пробовал:

1. Снижение количества одновременных потоков до 5-10 за раз решает проблему, но полностью разрушает параллельную производительность.

2. Я вижу количество потоков в журнале, и переполнения нет, максимум 30 потоков одновременно для A и B (приблизительно 60 приблизительно)

3. Попытка понизить System.Net.ServicePointManager.DefaultConnectionLimit , но это не поможет.

Похоже, что-то блокирует POST-запросы, а затем они просто спешат снова нормально. Пожалуйста, совет по этому вопросу. Спасибо.

PS: я работаю с Flickr запросами. Могут ли быть некоторые из их ограничений доступа? Зависание POST выглядит странно в любом случае, просто зависает без единого прохода.

Answer 1

Благодаря Polyfun было бы неплохо ограничить приложение меньшим количеством постоянно работающих потоков вместо бесконечного создания сотен потоков.

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