Ограничение коэффициентов производительности WebSocket в ASP.NET 4.5?

Документация MSDN, похоже, не имеет хорошего охвата поддержки ASP.net 4.5 HTML5 протокола WebSockets!

Это то, что я ищу:

Сколько подключений в реальном времени может поддерживать сервер/приложение/cpu?
Есть ли максимальное количество входящих соединений, которые можно было бы установить/получить?
Какое оптимальное количество сокетов для приложения независимо от передачи данных через сокет?

Update:

Запросы сокетов Flash RTMP (альтернативы websocket) могут быть хорошо настроены на сервере приложений Adobe Media Server. Разве не какие-либо конфигурации для количества запросов, идеального времени, размера кусков,... для ASP.net внутри приложения или конфигурации IIS 8?

Ответ 1

Кому может быть интересно:

Более 100 тыс. соединений WebSocket могут быть созданы на одном сервере запуск ASP.NET 4.5
Соединения WebSocket инициируются протоколом HTTP рукопожатие, поэтому некоторые из IIS дросселируют, которые применяются к HTTP-запросам будет также применяться к WebSockets. appConcurrentRequestLimit в конфигурации IIS можно использовать для установки максимальных одновременных запросов для каждого приложения:
```
<serverRuntime appConcurrentRequestLimit="250000" />
```
Максимальные параллельные подключения к веб-приложению ASP.net 4 могут быть установлены с помощью свойство ApplicationPool maxConcurrentRequestsPerCPU:
```
<system.web>
    <applicationPool maxConcurrentRequestsPerCPU="20000" />
</system.web>
```
Когда общий объем соединений превышает maxConcurrentRequestsPerCPU, ASP.NET начнет обрабатывать запросы с использованием очереди. Чтобы контролировать размер очереди, вы можете tweak machine.config requestQueueLimit:
```
<processModel autoConfig="false" requestQueueLimit="250000" />
```
Следует учитывать следующие счетчики производительности: проведение concurrency тестирования и настройки оптимальных настроек подробнее:
- NET CLR Память #bytes во всех Heaps
- ASP.NET\Requests Current - Queued - Отклонено
- Информация о процессоре\Время процессора
- Установлены соединения TCP/IP
- Веб-сервис\Текущие подключения - Максимальные подключения
- .NET CLR LocksAndThreads\# текущих логических потоков - # текущих физических потоков

Ответ 2

EDIT: Этот ответ связан с .NET 4.0 или более ранними версиями, где WebSockets должен быть реализован на вашем собственном (.Net 4.5 + IIS предоставляет вам решение). Таким образом, это относится только к вашей собственной реализации WebSockets поверх уровня TCP.

Количество сокетов, которые могут обрабатываться с помощью .Net, основано на системе и способе обслуживания сокетов. Прочитайте это: http://msdn.microsoft.com/en-us/library/windows/desktop/ms739169%28v=vs.85%29.aspx

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

Если вы используете собственную реализацию, основанную на raw TCP Sockets, тогда эта информация будет применяться:

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

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

Существует множество способов обслуживания сокетов, которые позволяют обрабатывать больше сокетов. Несколько основных моментов:

Блокирующий способ обслуживания сокетов задерживает обслуживание каждого сокета. Кроме того, неблокирующее чтение клиентских сокетов будет использовать ваш процессор для проверки наличия доступных данных. С огромным количеством сокетов это может быть очень дорого.
В потоке каждого клиентского сокета будет использоваться огромный объем памяти (более 1 мб на поток), что позволит вам получить небольшое количество сокетов на каждую физическую систему.
Один из лучших (imho) вариантов использует асинхронный сокет. Это позволяет вам иметь тысячи сокетов и с хорошей реализацией более десятков или даже сотен тысяч сокетов на одной серверной системе.