2010-10-29 7 views
0

Я планирую сделать программное обеспечение с большим количеством равноправных сетевых подключений. Обычно я создавал бы собственный поток для каждого соединения для отправки и получения данных, но в этом случае с 300-500 + соединениями это означало бы непрерывное создание и уничтожение большого количества потоков, которые, я думаю, были бы большими накладными расходами. И создание одного потока, который обрабатывает все соединения последовательно, вероятно, может немного замедлить работу. (Я не уверен в этом.)Как определить оптимальное количество потоков?

Вопрос: сколько потоков было бы оптимальным для решения таких проблем? Можно ли вычислить его в программном обеспечении, чтобы он мог сам решить создать меньше потоков на старом компьютере с не так много ресурсов и больше на новых?

Это теоретический вопрос, я бы не хотел, чтобы это было реализовано или зависит от языка. Однако я думаю, что многие люди будут советовать что-то вроде «Просто используйте ThreadPool, он будет обрабатывать такие вещи», так что скажем, это не будет приложение .NET. (Я, вероятно, должен использовать некоторые другие части кода в старом проекте Delphi, поэтому язык будет, вероятно, Delphi или, возможно, C++, но это еще не решено.)

+2

См. Http://stackoverflow.com/questions/481970/how-many-threads-is-too-many/481979#481979 – paxdiablo

+0

Какая у вас ОС? Окна? –

+0

Да, это Windows. – ytg

ответ

2

Если это Windows (вы упомянули .Net?), Вы должны обязательно реализовать это, используя I/O completion ports. Это наиболее эффективный способ подключения сокетов Windows I/O. В этой документации есть отдельная дискуссия по размеру пула потоков.

Наиболее важное свойство O порта ввода/ завершения внимательно рассмотреть этого значения параллелизма. Значение параллелизма для порта завершения указывается, когда оно создано с CreateIoCompletionPort через параметр Number4fconcurrentThreads . Это значение ограничивает количество запущенных потоков, связанных с портом завершения , связанным с портом завершения . Когда общее количество из запускаемых потоков, связанных с портом завершения достигает значения параллелизма, системные блоки выполнения любых последующих потоков, связанных с этим завершения порта, пока количество запускаемых потоков не упадет ниже значения параллелизма ,

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

Хороший бесплатный пример того, как это сделать, - the Free Framework. Есть некоторые ошибки, которые, глядя на рабочий код, могут помочь вам закоротить.

0
  1. Сделать число нитей настраивается.
  2. Задайте несколько конкретных конфигураций, которые являются наиболее распространенными, которые вы ожидаете поддерживать.
  3. Получите хороший профилировщик/запишите свой код, а затем тщательно проверьте различные значения 1. для всех различных типов 2. до тех пор, пока не найдете оптимальное значение, которое работает для каждой конфигурации.

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

Редактировать: +1 на вопрос, чья ссылка отправлена ​​paxDiablo выше в качестве комментария. Его почти тот же вопрос и множество загрузок информации, включая очень подробный ответ самого paxDiablo.

0

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

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

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

0

Один поток на процессор, обрабатывающий несколько (сотни) соединений.

9

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

В качестве общего руководства Goetz говорит о том,

темы = число процессоров + 1

для ЦП приложений, а также

количество процессоров * (1 + время ожидания/время обслуживания)

для связанных с IO контекстов

Смежные вопросы