Сколько гнездовых соединений возможно?

Ответ 1

Google для проблемы "C10K". Это в основном обсуждение и технология, позволяющая управлять 10000 или более одновременными соединениями.

Я подозреваю, что это число было выбрано потому, что это трудно, но теоретически возможно.

Ответ 2

Я достиг 1600k одновременных подключений к разъему без подключения и в то же время 57k req/s на рабочем столе Linux (16G RAM, I7 2600 CPU). Это один HTTP-сервер потока, написанный на C с epoll. Исходный код находится на github, здесь .

Edit:

Я сделал 600k одновременных HTTP-соединений (клиент и сервер) на одном компьютере с JAVA/ Clojure. подробнее post, обсуждение HN: http://news.ycombinator.com/item?id=5127251 p >

Стоимость соединения (с epoll):

• Приложению
• требуется некоторая оперативная память за соединение.
• TCP-буфер 2 * 4k ~ 10k или более
• epoll нужна некоторая память для файлового дескриптора, из epoll (7)

Каждый зарегистрированный файловый дескриптор стоит примерно 90               байтов на 32-битном ядре и примерно 160 байт на 64-битном ядре.

Ответ 3

Это зависит не только от конкретной операционной системы, но и от конфигурации, потенциально конфигурации в реальном времени.

Для Linux:

cat /proc/sys/fs/file-max

покажет текущее максимальное количество дескрипторов файлов, общее количество которых разрешено открывать одновременно. Проверьте http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html

Ответ 4

10000? 70000? что все:)

FreeBSD - это, вероятно, сервер, который вы хотите. Здесь небольшое сообщение в блоге о настройке для обработки 100 000 подключений, у него были некоторые интересные функции, такие как нулевые копии сокетов в течение некоторого времени, а также kqueue, чтобы действовать как механизм завершения завершения.

Solaris может обрабатывать 100 000 подключений в прошлом веке!. Говорят, что linux будет лучше

Лучшее описание, с которым я столкнулся, - это презентация/документ о создании масштабируемого веб-сервера. Он не боится сказать это так:)

То же самое для программного обеспечения: кретины на прикладной уровень принудительно инноваций на уровне ОС. Потому как Lotus Notes поддерживает одно TCP-соединение на одного клиента открыт, IBM внесла большой оптимизация для "одного процесса", 100.000 открытых подключений "для Linux

И планировщик O (1) был изначально созданный для хорошего выигрыша на некоторых нерелевантный тест Java. Дно что это раздувание выгодно для всех нас.

Ответ 5

В Linux вы должны смотреть на использование epoll для async I/O. Также может потребоваться тонкая настройка сокетов-буферов, чтобы не тратить слишком много места на одно соединение.

Я бы предположил, что вы сможете достичь 100k соединений на разумной машине.

Ответ 6

зависит от приложения. если с каждым клиентом всего несколько пакетов, 100K очень просто для Linux. Инженер моей команды провел тест несколько лет назад, результат показывает: когда нет установленного пакета от клиента после установления соединения, linux epoll может смотреть 400k fd для удобочитаемости при уровне использования процессора менее 50%.

Ответ 7

Ограничение количества открытых сокетов настраивается в файловой системе /proc

cat /proc/sys/fs/file-max

Макс для входящих подключений в ОС, определяемых целыми пределами.

Linux сама позволяет миллиарды открытых сокетов.

Для использования сокетов вам необходимо прослушивать приложение, например. веб-сервер, и он будет использовать определенный объем оперативной памяти для каждого сокета.

ОЗУ и ЦП будут вводить реальные пределы. (современный 2017 год, думаю, миллионы не миллиарды)

1 миллион возможен, нелегко. Ожидайте использовать X гигабайт оперативной памяти для управления 1 миллионом сокетов.

Исходящие TCP-соединения ограничены номерами портов ~ 65000 на IP. Вы можете иметь несколько IP-адресов, но не неограниченные IP-адреса. Это ограничение в TCP, а не Linux.

Ответ 8

Какая операционная система?

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

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

Кроме того, вам нужно будет профилировать, но мне удалось получить более 70 000 одновременных подключений на скромно заданном сервере (760 МБ памяти); см. здесь http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html для более подробной информации.

Очевидно, что если вы используете менее эффективную архитектуру, такую ​​как "поток на соединение" или "выберите", вы должны ожидать получить менее впечатляющие цифры; но, IMHO, просто нет причин выбирать такие архитектуры для серверов сокетов Windows.

Изменить: см. здесь http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx; то, как рассчитывается количество невыгружаемого пула, было изменено в Vista и Server 2008 и теперь доступно гораздо больше.

Ответ 9

Реально для приложения более 4000-5000 открытых сокетов на одной машине становятся непрактичными. Просто проверка активности на всех сокетах и ​​управление ими начинают становиться проблемой производительности, особенно в средах реального времени.