Самый эффективный счетчик потоков? - PullRequest
2 голосов
/ 02 марта 2011

У меня есть студенты, которым я помогаю с потоковым сервером. Они используют синхронные сокеты и один поток на клиента, что не очень эффективно. Лучше использовать асинхронные методы, чтобы позволить .Net использовать IOCP.

Дело в том, что я на самом деле не тратил время на размышления о том, когда асинхронные сокеты становятся более эффективными, чем архитектура с одним потоком / сокетом. IIRC это наиболее эффективно два имеют два потока на ядро?

Кто-нибудь может пролить свет на это? Когда асинхронные сокеты становятся более эффективными? Каково оптимальное количество потоков на ядро?

Ответы [ 3 ]

2 голосов
/ 02 марта 2011

Асинхронные сокеты всегда будут более эффективными.

Разница между синхронными и асинхронными сокетами заключается в том, что асинхронные сокеты используют порты завершения ввода / вывода вместо блокировки потока.Заблокированный поток потребляет дополнительные ресурсы, в основном память, по сравнению с отсутствием потока вообще.

Говорить о количестве потоков на ядро ​​просто неверно.
Самое эффективное число потоков - это один исполняющий поток наядро.Не больше, не меньше.В вашем случае с синхронным решением потоки будут заблокированы (и, следовательно, не выполняются на процессоре), пока они ждут данных.В асинхронном решении также не будет потоков, выполняющихся на ЦП во время ожидания данных (но будет меньше заблокированных потоков).Количество выполняющихся потоков будет одинаковым в обоих случаях, но асинхронный будет использовать меньше служебной памяти.

Редактировать:
Некоторые примечания относительно точно одного исполняющего потока на ядро.
Чем больше потоков, тем больше издержек на переключение контекста, а меньшее количество потоков приводит к тому, что некоторые ядра простаивают.
Но на самом деле получить идеальное количество потоков - непростая задача, когда ввод / вывод задействован, поскольку потоки не заняты все время.,Поэтому, если у вас есть потоки, заблокированные в ожидании ввода / вывода, у вас может быть больше потоков, чем ядер, но вы должны попытаться сбалансировать избыточное выделение потоков так, чтобы на каждом ядре фактически работал почти один поток.

Редактировать 2:
Еще одна заметка.Не беспокойтесь об эффективности при низкой нагрузке, такой как один или два клиента (если это не фактическое количество пользователей), оптимизируйте для максимально возможной нагрузки, вот тогда производительность будет иметь значение.

1 голос
/ 02 марта 2011

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

Это меняется, если сам обработчик асинхронного завершения выполняет много операций ожидания ввода-вывода (возможно, диска или базы данных), планировщику пула потоков может потребоваться некоторое время, чтобы догнать работников, которые еще не завершили работу, но не циклы горения Дополнительные потоки TP добавляются только дважды в секунду.

1 голос
/ 02 марта 2011

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

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