Сколько потоков использовать?
Я знаю, что есть некоторые существующие вопросы, и они дают очень хорошее общее взгляд на вещи. Я надеюсь получить некоторые подробности о C # / VB.Net для фактической реализации (не философии) некоторых из этих перспектив.
Мой частный случай
У меня есть служба WCF который, помимо прочего, принимает файлы. На протяжении большей части срока службы эта конкретная область фактически просто бездействует - когда работа все же приходит, она прибывает большими пакетами в очень разных количествах.
Для каждого полученного файла (которое максимум может составлять тысячи в секунду) служба должен работать с файлами в течение 1-10 секунд (каждый) в зависимости от ряда других служб, локальных ресурсов и времени ожидания сетевого ввода-вывода.
Чтобы помочь службе с этими пакетными рабочими нагрузками I внедрила систему очередей. Эти тысячи файлов, получаемых в секунду, помещаются в очередь. Контроллер вычисляет количество используемых потоков в зависимости от размера очереди, пока не будет достигнуто значение «Максимальное максимальное количество потоков», которое не позволяет ему создавать дополнительные потоки. Эти потоки помещаются в пул потоков и повторно используются для циклического прохождения очереди. Контроллер будет; с интервалами; пересчитайте необходимое количество потоков. Если размер очереди уменьшается, соответствующее количество потоков освобождается.
Давняя проблема
Сколько потоков я должен достичь пика ? Ясно, что добавление нового потока каждый раз при получении файла было бы глупо из-за отсутствия лучшего слова - производительность в лучшем случае ухудшилась бы. Ограничение потоков, когда загрузка ЦП составляет всего 10% по каждому ядру, также не кажется лучшим использованием ресурсов.
Итак, есть ли подходящий способ определить, сколько потоков нужно ограничить? Я бы предпочел, чтобы служба могла определить это сама путем выборки доступных ресурсов, но есть ли снижение производительности от этого? Я знаю, что наиболее распространенным ответом является мониторинг рабочих нагрузок, корректировка счетчиков методом проб и ошибок, пока я не найду число, которое мне нравится, но из-за характера этой службы (длительные периоды простоя с последующими высокими / пиковыми рабочими нагрузками) это может занять много времени. пора получить такую информацию.
Что тогда, если мы переместим образ сервера на другой хост, который быстрее / медленнее / отличается от первого? Мне нужно заново выполнить выборку процесса?
В идеале, что мне нужно, это чтобы координатор разумно увеличивал размер пула потоков до тех пор, пока загрузка ЦП не достигнет x% ( будет ли 80% разумным? 90%? 99%?). Ясно, что я хочу сделать это, не добавляя больше потоков, чем необходимо для достижения x%, в противном случае все, что у меня получится, это потоки, не просто ожидающие ресурсов ввода-вывода, но и друг друга.
Заранее спасибо!
Связанные вопросы (если вам нужны общие идеи):
Сколько потоков слишком много?
Сколько потоков создать и когда?
Сложность для вас
Где было бы весело, если бы я не усложнял задачу?
В настоящее время служба регулярно загружает 100% ЦП во время этих всплесков. Проблема в скачках загрузки процессора. Он переходит от холостого хода (0-10%) к 100%, а затем снова вниз. Я не уверен, что смогу с этим помочь - в идеале я бы не доводил все до 100%. Проблема существует из-за того, что упомянутые файлы на самом деле являются изображениями, и часть процесса служб заключается в передаче изображения в черный ящик System.Windows.Media, который выполняет для меня сложную обработку изображений.
Между пиками возникают паузы из-за ожидания ввода-вывода и другой продолжающейся обработки. Если пики, достигающие 100%, ничем не помогут (а я знаю, как это предотвратить, или если нужно), как я должен стремиться к тому, чтобы график загрузки процессора выглядел? Сидел постоянно на 100%? Подпрыгивает между 50-100? Если я попытаюсь выполнить выборку, чтобы решить, что мне кажется наиболее эффективным, гарантировано ли, что переключение хоста виртуальных серверов также будет работать лучше всего с тем же графиком?
Эту дополнительную сложность я не буду принимать во внимание для тех из вас, кто готов ответить. Не стесняйтесь игнорировать этот раздел. Однако любой ответ, который также объясняет это осложнение,или даже ответы, которые просто дают советы о том, как с этим справиться, я, по крайней мере, проголосую за!
Чертовски длинный вопрос - извините за это - и спасибо, что так много прочитали !!