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

Ответ 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) вариантов использует асинхронный сокет. Это позволяет вам иметь тысячи сокетов и с хорошей реализацией более десятков или даже сотен тысяч сокетов на одной серверной системе.