Многопоточность: В какой точке Вы создали слишком много потоков?
Одна причина, о которой я могу думать, состоит в том, что проверка диапазона легче. Учитывая, что большинство перечислений запускается в 0, необходимо было бы только проверить верхнюю границу.
2 ответа
Вы создали слишком много потоки, когда общая производительность вашего приложения ухудшается, или влияние на другие приложения, запущенные на том же самом компьютере, отрицательно сказывается до неприемлемого уровня.
Дело в том, что нет однозначного ответа.
Одно приложение, которое я использовал работая над, использует пул потоков из 1000 потоков, и для того, что мы делаем, это число кажется правильным. В одной конфигурации мы не ограничивали его, и он увеличился до 30 000+ и, по сути, остановил машину.
По сути, вам нужно протестировать ее производительность и иметь достаточно средств мониторинга / инструментов для определения общей пропускной способности вашего приложения. , использование ресурса, использование потоков и знать, каковы были простаивающие потоки и как долго работа ожидала в очередях, чтобы быть поднятыми. Затем вы настраиваете по мере необходимости.
Одно предостережение: очень хорошо подумайте, прежде чем добавлять еще один слой нитей. Как я уверен, вы знаете, писать многопоточный код сложно. Постарайтесь сделать это как можно проще. Добавление еще одного слоя - рискованный шаг.
Никто не может дать вам простой числовой ответ, потому что он слишком зависит не только от того, сколько ядер и т. Д. У машины, но и от того, какие другие задачи (если таковые имеются) эта машина должна выполнять в в то же время, что и ваше приложение, И о том, что именно ваши потоки делают.
Приведу пример последней проблемы: однажды у меня был довольно простой "обходчик" где определенное количество потоков было посвящено страницам HTTP GET, которые, как я определил, мне нужны - каждый поток большую часть времени блокировал вызовы сокетов для выполнения HTTP GET, и поэтому для получения довольно хорошей производительности мне понадобилось их большое количество (сотни). Позже я переключил базовый подход на использование асинхронного сетевого ввода-вывода вместо блокировки сокетов - и внезапно каждый поток мог легко иметь сотни URL-адресов «в полете», поэтому наличие сотен таких активных потоков привело бы к перегрузке системы, что, вероятно, привело бы к Открыто больше сокетов, чем могла обработать система (это был не очень большой или хорошо настроенный сервер! -), что привело к сбою или, по крайней мере, ужасному замедлению работы из-за чрезмерного обмена местами и т. д.
Так что даже для потоков, полностью связанных с вводом-выводом, точная форма ввода-вывода, которую они используют (блокирующая или асинхронная, например) будет иметь огромное влияние на то, какое количество потоков (или процессов, или любых других подобных единиц) будет оптимальным для определенной общей программной задачи. Очевидно, что потоки, выполняющие больше работы, связанной с процессором, должны быть откалиброваны (для максимальной производительности) по доступности ядер и оперативной памяти, в которой ядра могут работать, но, возможно, также и других ресурсов (например, если некоторые из ваших потоков могут использовать доступные Графические процессоры или другие специализированные процессоры для делегирования части своей работы).
В конце концов, вы можете сделать разумную приблизительную оценку, зная все такие параметры, но вы можете ошибиться из-за существенного фактора - так что сравнительный анализ реалистичная рабочая нагрузка с (скажем) вдвое или вдвое большим количеством потоков, как вы предполагаете, должна быть оптимальной, - отличный способ потратить время и ресурсы на поздних этапах настройки производительности при развертывании. В общем, поведение производительности OFTEN оказывается удивительным даже для очень опытных архитекторов, разработчиков и системных администраторов, поэтому нет действительно хорошей замены подходу реалистичных тестов, тщательного измерения и соответствующей настройки на основе эмпирических данных. (Имейте в виду, слепой эмпиризм - просто попытка приспособиться к экспериментальным наблюдениям без какой-либо разумной модели, чтобы понять их - почти так же плох, как догматические и доктринальные подходы, игнорирующие данные, но это еще одна напыщенная речь ; -).
поэтому нет действительно хорошей замены подходу, основанному на эмпирических данных, в виде реалистичных тестов, тщательного измерения и соответствующей настройки. (Имейте в виду, слепой эмпиризм - просто попытка приспособиться к экспериментальным наблюдениям без какой-либо разумной модели, чтобы понять их - почти так же плох, как догматические и доктринальные подходы, игнорирующие данные, но это еще одна напыщенная речь ; -). поэтому нет действительно хорошей замены подходу, основанному на эмпирических данных, в виде реалистичных тестов, тщательного измерения и соответствующей настройки. (Имейте в виду, слепой эмпиризм - просто попытка адаптироваться к экспериментальным наблюдениям без какой-либо разумной модели, чтобы понять их - почти так же плох, как догматические и доктринальные подходы, игнорирующие данные, но это еще одна напыщенная речь ; -).