Задачи Intel TBB для обслуживания сетевых подключений — хорошая модель?
Я разрабатываю бэкэнд для сетевого продукта, который обслуживает дюжину клиентов (N = 10-100). Каждое соединение требует 2 периодических задач, сердцебиение и загрузка телеметрии через SSH, каждое в H Гц. Есть также дополнительные события различного рода, поступающие с внешнего интерфейса. По характеру каждой из задач, есть большая часть ожидания в select вызовите сокет каждого соединения, что позволяет ОС часто переключаться между потоками для обслуживания других клиентов в ожидании ответа.
В моей первоначальной реализации я создавал 3 потока для каждого соединения (сердцебиение, телеметрия, дополнительные), каждый из которых ожидал одну переменную условия, которая высовывается каждый раз, когда в рабочей очереди нужно что-то делать. Рабочая очередь заполняется вышеупомянутыми периодическими событиями с использованием таймера и команд из внешнего интерфейса.
У меня есть несколько вопросов здесь.
-
Будет ли хорошей идеей переключить подход пула рабочих потоков на задачи Intel TBB? Если да, то какое значение потоков мне нужно инициализировать
tbb::task_scheduler_init? -
В текущем подходе 300 потоков ожидают условную переменную, которая
signalизданиеN * H * 3раз в секунду это может стать узким местом для масштабируемости (особенно на стороне, которая вызываетsignal). Есть ли лучшие способы для пробуждения только одного работника за задачу? -
Как осуществляется пробуждение рабочего потока в TBB?
Спасибо за ваши предложения!
Решение
Трудно сказать, будет ли переход на TBB хорошим подходом или нет. Каковы ваши требования к производительности и каковы показатели производительности для текущей реализации? Если текущее решение достаточно хорошее, его, вероятно, не стоит переключать.
Если вы хотите сравнить оба (текущее значение против TBB), чтобы узнать, что дает лучшую производительность, то вы можете сделать то, что называется «Tracer bullet» (из книги Прагматичный программист) для каждой реализации и сравнить результаты. Проще говоря, сделайте сокращенный прототип каждого и сравните результаты.
Как уже упоминалось в этот ответ, Обычно не стоит пытаться улучшить производительность, не имея конкретных доказательств того, что то, что вы собираетесь изменить, улучшится.
Помимо всего этого, вы могли бы рассмотреть возможность создания пула потоков с числом потоков, являющимся некоторой функцией числа ядер ЦП (возможно, в 1 или 1,5 потоков на ядро). Потоки будут отбирать задачи из общей рабочей очереди. , Было бы 3 типа задач: сердцебиение, телеметрия, дополнительные. Это должно уменьшить негативные последствия, вызываемые переключением контекста при использовании большого количества потоков.
Другие решения
Других решений пока нет …