Каковы недостатки модели «поток на соединение»?

Один из пунктов молитвы о распределенных системах звучит так:

Я реализовал модель потока на соединение

У меня есть следующие вопросы по этому заявлению:

  1. Каковы недостатки этой модели при проектировании серверной/распределенной системы?
  2. Какой подход будет работать лучше в большинстве случаев?
  3. В каких случаях это может быть правильным подходом?

multithreading distributed-computing network-programming distributed-system language-agnostic
person syntagma    schedule 25.08.2016    source источник
comment
1. Масштабируемость, хотя были построены такие системы, которые обрабатывают 100 000 подключений, так что на самом деле это не проблема, которую рисуют. 2. Этот. 3. Все, кроме самых тяжелых. Ваша ссылка забавна, но ненаучна.   -  person user207421    schedule 25.08.2016
comment
Поток слишком дорог, чтобы поддерживать соединение с задержкой, измеряемой несколькими миллисекундами, и, как правило, его нужно обслуживать только за секунды. Умный способ сделать это - использовать поток только тогда, когда соединение должно выполнять работу, IOCP - это способ сделать это.   -  person Hans Passant    schedule 25.08.2016

Ответы (2)


arrow_upward
1
arrow_downward

  1. Каковы недостатки этой модели при проектировании серверной/распределенной системы?

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

У вас также могут возникнуть проблемы с производительностью или надежностью, когда многие потоки пытаются получить доступ к общим данным, или если ваша ОС не интегрирует сетевые события для пробуждения потока.

  1. Какой подход будет работать лучше в большинстве случаев?

В большинстве случаев это работает нормально - в большинстве систем достаточно памяти для ~ 10 000 одновременных клиентов (или ~ 1000 в Windows, если вы не удосужились установить размер стека для потоков и оставить его равным 1 МБ).

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

  1. В каких случаях это может быть правильным подходом?

Это почти никогда не является технически «наилучшим» подходом, но иногда имеет прагматический инженерный смысл.

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

person Pete Kirkham    schedule 25.08.2016

arrow_upward
0
arrow_downward

Каковы недостатки этой модели при проектировании серверной/распределенной системы?

Одно соединение = один поток. Это влияет на масштабируемость сервера, поскольку количество подключений может значительно превысить идеальное количество потоков вашей системы.

Какой подход будет работать лучше в большинстве случаев?

пул потоков исполнителей. задача, которая должна быть выполнена для каждого соединения (если есть), ставится в очередь в пуле, поток завершает задания в fifo.

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

Не знаю ни одного из этих случаев.

person UmNyobe    schedule 25.08.2016