Вкратце: вы должны иметь возможность достичь порядка миллионов одновременных активных TCP-соединений и HTTP-запросов по расширению. Это говорит о максимальной производительности, которую вы можете ожидать от правильной платформы с правильной конфигурацией.
Сегодня меня беспокоило, будет ли IIS с ASP.NET поддерживать порядка 100 одновременных подключений (посмотрите мое обновление, ожидайте ~ 10 тыс. Ответов в секунду в более старых версиях ASP.Net Mono). Когда я увидел этот вопрос / ответы, я не смог удержаться от ответа сам, многие ответы на этот вопрос здесь совершенно неверны.
Лучший случай
Ответ на этот вопрос должен касаться только простейшей конфигурации сервера, чтобы отделиться от бесчисленных переменных и конфигураций, возможных ниже по течению.
Итак, рассмотрим следующий сценарий моего ответа:
- Нет трафика в сеансах TCP, за исключением пакетов проверки активности (в противном случае вам, очевидно, потребуется соответствующая пропускная способность сети и другие ресурсы компьютера)
- Программное обеспечение, предназначенное для использования асинхронных сокетов и программирования, а не аппаратного потока на запрос из пула. (например, IIS, Node.js, Nginx ... веб-сервер [но не Apache] с программным обеспечением, разработанным для асинхронного программирования)
- Хорошая производительность / доллар CPU / Ram. Сегодня условно допустим i7 (4 ядра) с 8 ГБ ОЗУ.
- Хороший межсетевой экран / роутер под стать.
- Нет виртуального лимита / регулятора - т.е. Linux somaxconn, IIS web.config ...
- Нет зависимости от другого более медленного оборудования - нет чтения с жесткого диска, потому что это будет наименьший общий знаменатель и узкое место, а не сетевой ввод-вывод.
Подробный ответ
Синхронные проекты с привязкой к потоку, как правило, хуже всего работают по сравнению с реализациями асинхронного ввода-вывода.
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, предназначенные для этой конкретной роли более эффективно, чем ЦП общего назначения.
Хороший выбор дизайна программного обеспечения
Дизайн асинхронного ввода-вывода будет отличаться в зависимости от операционных систем и платформ программирования. Node.js был разработан с учетом асинхронности . По крайней мере, вы должны использовать Promises, а когда появится ECMAScript 7, async/ await. C # /. Net уже имеет полную поддержку асинхронного режима, такую как node.js. Независимо от ОС и платформы, следует ожидать, что асинхронный режим будет работать очень хорошо. И какой бы язык вы ни выбрали, ищите ключевое слово «асинхронный», большинство современных языков будут иметь некоторую поддержку, даже если это какое-то дополнение.
В WebFarm?
Каким бы ни был предел для вашей конкретной ситуации, да, веб-ферма - хорошее решение для масштабирования. Для этого существует множество архитектур. Один из них использует балансировщик нагрузки (хостинг-провайдеры могут предлагать их, но даже у них есть ограничение вместе с потолком пропускной способности), но я не поддерживаю этот вариант. Для одностраничных приложений с длительными соединениями я предпочитаю вместо этого иметь открытый список серверов, которые клиентское приложение будет выбирать случайным образом при запуске и повторно использовать в течение всего жизненного цикла приложения. Это устраняет единую точку отказа (балансировщик нагрузки) и обеспечивает масштабирование через несколько центров обработки данных и, следовательно, гораздо большую пропускную способность.
Разрушая миф - 64К портов
Чтобы ответить на вопрос, относящийся к «64 000», это заблуждение. Сервер может подключаться к более чем 65535 клиентам. См. Https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284
Кстати, Http.sys в Windows позволяет нескольким приложениям использовать один и тот же порт сервера в соответствии со схемой URL-адреса HTTP. Каждый из них регистрирует отдельную привязку домена, но в конечном итоге существует одно серверное приложение, проксирующее запросы к правильным приложениям.
Обновление 2019-05-30
Вот актуальное сравнение самых быстрых HTTP-библиотек - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- Дата тестирования: 2018-06-06
- Используемое оборудование: Dell R440 Xeon Gold + 10 GbE
- У лидера ~ 7 миллионов ответов в открытом виде в секунду (ответы, а не соединения)
- Второй Fasthttp для golang рекламирует 1,5 млн одновременных подключений - см. Https://github.com/valyala/fasthttp
- Ведущие языки - Rust, Go, C ++, Java, C и даже C # - 11 (6,9 Мбайт в секунду). Scala и Clojure занимают более низкое положение. Python занимает 29-е место со скоростью 2,7 млн в секунду.
- В конце списка отмечу laravel и cakephp, rails, aspnet-mono-ngx, symfony, zend. Все ниже 10к в секунду. Обратите внимание, что большинство этих фреймворков построено для динамических страниц и довольно старые, могут быть более новые варианты, которые находятся выше в списке.
- Помните, что это открытый текст HTTP, а не для специализации Websocket: многие люди, приходящие сюда, вероятно, будут заинтересованы в одновременных соединениях для websocket.