Скажите, должен ли я получать общий, виртуальный или выделенный хостинг, я где-то читал, что сервер/машина может обрабатывать только 64 000 TCP-соединений за один раз, это правда? Сколько может обрабатывать любой тип хостинга независимо от пропускной способности? Я предполагаю, что HTTP работает через TCP.
Было ли это означать, что только 64 000 пользователей могли бы подключиться к веб-сайту, и если бы я хотел больше обслуживать, мне пришлось бы перейти на веб-ферму?
Вкратце: Вы должны иметь возможность достичь порядка миллионов одновременных активных TCP-соединений и HTTP-запросов расширения.
Сегодня я был обеспокоен тем, поддерживает ли IIS с ASP.NET порядка 100 одновременных подключений. Когда я увидел этот вопрос/ответы, я не мог устоять перед ответом, многие ответы на этот вопрос совершенно неверны.
Лучший случай
Ответ на этот вопрос должен касаться только простейшей конфигурации сервера, чтобы отделить от бесчисленных переменных и конфигураций, доступных ниже по течению.
Итак, рассмотрим следующий сценарий для моего ответа:
Подробный ответ
Синхронные проекты, связанные с нитями, как правило, хуже всего относятся к асинхронным реализациям ввода-вывода.
WhatsApp получает миллион С трафика на одной операционной системе Unix с ароматизированной ОС - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/.
И, наконец, этот http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html вникает в детали, изучая, как можно было бы достичь даже 10 миллионов. Серверы часто имеют аппаратные устройства разгрузки TCP, ASIC, предназначенные для этой конкретной роли, более эффективно, чем CPU общего назначения.
Хороший выбор дизайна программного обеспечения
Асинхронная конфигурация ввода-вывода будет различаться на платформах операционных систем и программирования. Node.js был разработан с асинхронным учетом. Вы должны использовать Promises по крайней мере, и когда ECMAScript 7 появится, async/await. С#/.NET уже имеет полную асинхронную поддержку, например Node.js. Независимо от ОС и платформы, ожидается, что асинхронный режим будет работать очень хорошо. И какой бы язык вы ни выбрали, ищите ключевое слово "асинхронный", большинство современных языков будут иметь некоторую поддержку, даже если это надстройка какого-то рода.
В WebFarm?
Каким бы ни был предел для вашей конкретной ситуации, да, веб-ферма - одно из лучших решений для масштабирования. Для достижения этой цели существует множество архитектур. Один использует балансировщик нагрузки (хостинг-провайдеры могут их предлагать, но даже у них есть предел, а также потолок пропускной способности), но я не одобряю этот вариант. Для приложений с одной страницей с длительными подключениями я предпочитаю вместо этого иметь открытый список серверов, которые клиентское приложение будет выбирать из случайного при запуске и повторном использовании в течение всего срока службы приложения. Это удаляет единственную точку отказа (балансировщик нагрузки) и позволяет масштабировать несколько центров обработки данных и, следовательно, значительно увеличить пропускную способность.
Разрушение мифа - порты 64K
Чтобы решить вопрос о компоненте "64 000", это неправильное представление.
Поле TCP Port - 2x байта, которое может содержать 65536, но это не ограничивает количество клиентов до ~ 64k. Каждый TCP-пакет имеет два поля портов один для адресата и один для источника (а также два IP-адреса).
С TCP:
Это означает, что существует только предел количества серверов, к которым клиент может подключаться (на каждый IP-адрес клиента), а не наоборот (не сколько клиентов подключается сервер).
Теоретически, на одном принимающем порту (игнорируя многие другие практические ограничения), сервер может прослушивать один порт для каждого интернет-IP-адреса и каждого порта с этого IP-адреса - для IPv4, прибл. 2 ^ 32 * 2 ^ 16 (практически вам нужно будет вычесть некоторые зарезервированные IP-блоки и диапазоны портов). У этих клиентов в свою очередь не будет больше портов для подключения к любому другому серверу в Интернете.Кстати, Http.sys в Windows позволяет нескольким приложениям совместно использовать один и тот же порт сервера в схеме URL-адреса HTTP. Каждый из них регистрирует отдельную привязку домена, и все еще существует одно серверное приложение, которое проксирует запросы к правильным приложениям.
Этот вопрос довольно сложный. Нет никакого реального ограничения программного обеспечения на количество активных соединений, которые может иметь машина, хотя некоторые ОС более ограничены, чем другие. Проблема становится одним из ресурсов. Например, допустим, что одна машина хочет поддерживать 64 000 одновременных подключений. Если сервер использует 1 МБ ОЗУ для каждого соединения, ему потребуется 64 ГБ ОЗУ. Если каждому клиенту необходимо прочитать файл, загрузка доступа к массиву дисков или хранилища становится намного больше, чем могут обрабатывать эти устройства. Если серверу необходимо разветвлять один процесс на одно соединение, то ОС будет тратить большую часть времени на переключение времени или процессы голодания для процессорного времени.
Страница C10K problem имеет очень хорошее обсуждение этой проблемы.
Чтобы добавить мои два цента в разговор, процесс может одновременно открыть несколько сокетов, связанных с этим номером (в системах типа Linux)/proc/sys/net/core/somaxconn
cat/proc/sys/net/core/somaxconn
Этот номер может быть изменен "на лету" (конечно, конечно, конечно, root)
echo 1024 > /proc/sys/net/core/somaxconn
Но полностью зависит от серверного процесса, аппаратного обеспечения машины и сети, реального количества сокетов, которые могут быть подключены до сбоя системы.
Обратите внимание, что HTTP обычно не поддерживает открытие TCP-соединений дольше, чем требуется для передачи страницы клиенту; и обычно пользователю требуется гораздо больше времени для чтения веб-страницы, чем требуется для загрузки страницы... пока пользователь просматривает страницу, он вообще не загружает сервер.
Таким образом, количество людей, которые могут одновременно просматривать ваш веб-сайт, намного больше, чем количество TCP-соединений, которые он может одновременно обслуживать.
Похоже, что ответ составляет не менее 12 миллионов, если у вас есть многообещающий сервер, ваше серверное программное обеспечение оптимизировано для него, у вас достаточно клиентов. Если вы протестируете один клиент на один сервер, количество номеров портов на клиенте станет одним из очевидных пределов ресурсов (каждое TCP-соединение определяется уникальной комбинацией номера IP и порта в источнике и получателе).
(Вам нужно запустить несколько клиентов, так как в противном случае вы попадаете в предел 64K для номеров портов)
Когда дело доходит до этого, это классический пример остроты, что "разница между теорией и практикой на практике гораздо больше, чем в теории" - на практике достижение более высоких чисел представляется циклом a. предложить конкретные изменения конфигурации/архитектуры/кода, b. испытайте его, пока не достигнете предела, c. Я закончил? Если нет, то d. выяснить, что является ограничивающим фактором, например. вернитесь к шагу a (полоскание и повторение).
Вот пример с 2 миллионами TCP-соединений на жестком поле (128 ГБ оперативной памяти и 40 ядер), работающих под управлением Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - они закончились требующих 50 или около того достаточно значительных серверов, чтобы обеспечить загрузку клиента (их первоначальные более мелкие клиенты были превышены до раннего времени, например "maxed our 4core/15gb box @450k clients" ).
Вот еще одна ссылка для этого времени на 10 миллионов: http://goroutines.com/10m.
Это похоже на java based и 12 миллионов соединений: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/
Здесь два разных обсуждения: один - сколько людей может подключиться к вашему серверу. Этому ответили адекватно другие, поэтому я не буду вдаваться в это.
Другое - сколько портов ваш сервер может прослушивать? Я считаю, что это то, откуда пришел номер 64K. Фактически, протокол TCP использует 16-разрядный идентификатор для порта, что соответствует 65536 (бит более 64 КБ). Это означает, что на вашем IP-адресе может быть много разных "слушателей".
Я думаю, что количество параллельных подключений сокетов, которые может обрабатывать один веб-сервер, во многом зависит от количества ресурсов, потребляемых каждым соединением, и количества общего ресурса, доступного на сервере, запрещающего конфигурацию ресурсов любого другого веб-сервера.
Чтобы проиллюстрировать, если каждое соединение сокета, потребляемое 1 МБ ресурса сервера, и на сервере имеется 16 ГБ ОЗУ (теоретически), это будет означать, что он сможет обрабатывать одновременные соединения (16 ГБ /1 МБ). Я думаю, это так просто... ДЕЙСТВИТЕЛЬНО!
Поэтому, независимо от того, как веб-сервер обрабатывает соединения, каждое соединение в конечном итоге потребляет некоторый ресурс.