Ограничение факторов производительности WebSocket в ASP.NET 4.5? - PullRequest
22 голосов
/ 02 апреля 2012

Документация MSDN, по-видимому, недостаточно освещена в ASP.net 4.5 с поддержкой HTML5 Протокол WebSockets !

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

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

Обновление:

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

Ответы [ 2 ]

34 голосов
/ 20 апреля 2012

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

  • Более 100 тыс. Подключений WebSocket могут быть установлены к одному серверу с ASP.NET 4.5
  • Соединения WebSocket инициируются HTTPрукопожатие, следовательно, некоторые из IIS дросселей, которые применяются к HTTP-запросам , также будут применяться к WebSockets.appConcurrentRequestLimit в конфигурации IIS можно использовать для установки максимального числа одновременных запросов для приложения:

    <serverRuntime appConcurrentRequestLimit="250000" />
    
  • Максимальное количество одновременных подключений к ASP.net 4 WebПриложение может быть установлено с помощью свойства maxConcurrentRequestsPerCPU ApplicationPool:

    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
    
  • Когда общее количество соединений превышает настройку maxConcurrentRequestsPerCPU, ASP.NET начнет регулировать запросы, используя очередь.Чтобы контролировать размер очереди, можно настроить machine.config requestQueueLimit :

    <processModel autoConfig="false" requestQueueLimit="250000" />
    
  • Следующие счетчики производительности должны бытьучитывается при проведении параллельного тестирования и настройке оптимальных настроек, описанных выше:

    • NET CLR Память # байтов во всех кучах
    • ASP.NET \ Запросы Текущий - В очереди - Отклонено
    • Информация о процессоре \ Время процессора
    • Установленные соединения TCP / IP
    • Веб-служба \ Текущие соединения - Максимальное количество соединений
    • .NET CLR LocksAndThreads \ # текущих логических потоков - #текущих физических потоков
0 голосов
/ 04 апреля 2012

РЕДАКТИРОВАТЬ: Этот ответ относится к .Net 4.0 или более ранним версиям, где WebSockets должны быть реализованы самостоятельно (.NET 4.5 + IIS предоставляет вам решение). Так что это относится только к вашей собственной реализации WebSockets поверх TCP Layer.

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

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

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

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

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

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

  1. Блокировка способа подачи розеток приведет к задержке обслуживания каждой розетки. Также неблокирующее чтение клиентских сокетов будет использовать ваш процессор только для проверки наличия каких-либо данных. С огромным количеством розеток это может быть очень дорого.

  2. Поток на сокет клиента будет использовать огромный объем памяти (более 1 МБ на поток), что позволит вам использовать небольшое количество сокетов на физическую систему.

  3. Одним из лучших (imho) вариантов является использование асинхронного сокета. Это позволяет иметь тысячи сокетов, а при хорошей реализации - более десятков или даже сотен тысяч сокетов в одной серверной системе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...