Должен ли я инкапсулировать задачу в классе?

Question

Я создаю приложение, имеющее несколько длинных рабочих потоков, которые должны работать 24x7. Каждый рабочий - это метод в классе, который называется Bot. Пуск/Стоп Bot контролируется самим классом. Поэтому, если мне нужно 10 ботов, мне просто нужно создать экземпляр 10 Bot, сохранить в List<Bot> и начать с каждого из них. У меня также есть BotManager класс для управления всеми в настоящее время работает Bot

Теперь я хотел бы использовать Task вместо Thread для каждого из рабочих, так как они только тратят меньше, чем 5% от времени делать какие-либо обработки.

Должен ли я хранить Task в каждом классе или должен ли я наследовать свой Bot от Task?

Answer 1

Я бы не спустился с Task. Вы действительно не расширяете идею «задачи» и делаете что-то, что для кода, использующего его, является задачей с дополнительными функциями; вместо этого вы просто делаете что-то, что позволяет использовать задачи для его реализации.

Я также не уверен Task здесь очень подходит. Если идея в том, что они продолжают работать в фоновом режиме, то это не играет в сильные стороны TPL. Лучшее время для использования Task - это когда вам нужна композиция - четко определенная задача, которая запускается, завершается, а затем уведомляет о других задачах, которые она выполняет, и они могут приступить к работе над ее результатами.

Answer 2

Это определенно не «задача» для задач. Используйте потоки. Когда вам нужна уверенность, что ваш код фактически запущен (и на фиксированном количестве потоков), вы не можете использовать задачи. Задачи не гарантируют параллельное выполнение. Вы должны сами выделять темы. Если вы хотите сохранить ресурсы, уменьшите размер стека потоков с помощью конструктора.

Answer 3

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

Я бы сказал, что TPL (Tasks) будет лучшим вариантом. Пожалуйста, ознакомьтесь с http://msdn.microsoft.com/en-us/library/dd537609.aspx

Мы поможем вам больше, если вы разделяете характер своей работы, которую вы хотите выполнять параллельно. Что именно вы подразумеваете под 248 работающими задачами? Какую работу выполняют ваши задачи? Является ли это вычислением или IO (операция БД/Веб-служба)?

Я предполагаю, что каждый запрос состоит из 4 шагов, и эти шаги выполняются в следующей последовательности, 1. DB просмотровых 2. Веб-служба вызова 3. Обновление БД 4. Войдите в меню Файл

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

Далее вы сказали,

ресурсоемкой часть будет дб поиск

Но я понимаю, что дб поиск не использует CPU и это деятельность I/O и снова хороший кандидат для асинхронной задачи ввода-вывода.

Учитывая все эти предположения я предлагаю следующие,

1. DB Посмотрите вверх (Run асинхронно, так что поток пул потоков будет освобожден для обработки других запросов)
2. веб-службы вызова (Запуск асинхронно так, что нить пул потоков будет освобожден для обработки других запросов)
3. DB Update (Выполнить синхронно)
4. Вход в меню Файл (асинхронное протоколирование в зависимости от размера содержимого журнала)

По моему мнению, ни один из ваших шагов не требует интенсивного процессора, поэтому вы видите только 5% от использования ЦП.

Вы также упоминали,

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

Возможно, вы имели в виду как можно больше таких запросов (состоит из этих 4 шагов)? Если это так, вам не нужно добавлять лишние вещи. Поскольку, когда запрос ожидает асинхронного вызова, он освобождает поток пула потоков, и система может использовать его для обработки другого запроса. Это увеличит пропускную способность.

Должен ли я сохранять задание в каждом классе или должен ли я наследовать свой бот от Задание?

1 Bot представляют 1 запрос. Задачи представляют собой шаги в рамках запроса. Поэтому создавайте задачи в своем классе BOT.

Запустите его с различным количеством запросов и проверьте использование CPU, Memory и других системных ресурсов.