Проблема производительности IIS, пытающаяся реализовать XMPP-подобный протокол


3

У нас есть клиент, которому необходимо получать интерактивные сообщения с сервера, от клиентов, которые распространяются по всему миру за всеми видами брандмауэров со всеми закрытыми портами. Единственное, на что мы можем положиться, это HTTP-порт 80 (и HTTPS 443).

Дизайн в основном моделируется после XMPP (протокол Jabber) с использованием нашего клиента и IIS. Клиент отправляет запросы GET в обработчик .NET; обработчик удерживает запрос открытым для поиска сообщений. Если какие-либо сообщения поступают, они немедленно отправляются клиенту; если нет, то после таймаута соединение закрывается с ответом «нет данных». Клиент немедленно открывает связь.

Ну, теоретически.

Что происходит на первый взгляд, IIS не может обрабатывать более 100 одновременных запросов - остальные все находятся в очереди, и между «подключенными» и IIS может быть несколько минутного разрыва, признавая, что клиент вызвал. Во-вторых, примерно в половине случаев, когда клиент уходит без ответа с сервера (время ожидания клиента на пять минут больше, чем у сервера).

POST всегда работает. Другие данные, обслуживаемые на одном и том же веб-сервере, работают. Веб-службы на одном сервере работают. Это готовая установка на сервере Windows 2K3.

Есть ли вариант конфигурации, который нам не хватает, или есть что-то еще, на что я должен обратить внимание?

Спасибо.

3

Я думаю, что вы используете лимиты пула потоков ASP.NET, а не IIS. Посмотрите на создание асинхронного HTTP-обработчика (IHttpAsyncHandler), как при блокировке/ожидании они не связывают пул потоков (вместо этого они используют порты завершения).

Update: Наткнулся это последнее, что, кажется, согласны с моим мышлением: CodeProject: Scalable COMET Combined with ASP.NET


1

Если IIS не соответствует вашим требованиям, вы должны выбрать другой веб-сервер, например ApacheMod_mono) или LightTPD.

BTW, вы можете туннелировать XMPP через HTTP, используя XMPP Over BOSH. Не нужно изобретать собственный протокол.


0

XMPP никогда не предназначены для высокопроизводительных приложений. Сообщения должны проходить через весь стек до уровня приложения, и существует много разбора XML. Рассматривали ли вы использование какого-либо другого стандарта помимо XMPP?

+2

«XMPP никогда не был предназначен для высокопроизводительных приложений». Я не знаю, что вы подразумеваете под «высокой производительностью», но он был разработан для общения в чате и делает это очень хорошо, о чем спрашивает OP. Например, ejabberd может обрабатывать сотни тысяч одновременных запросов. 21 янв. 112011-01-21 16:33:38


1

Из окон окна требуется некоторое подергивание. Мне пришлось реализовать кометный сервер в asp.net и наткнулся на некоторые глупые значения по умолчанию.После прочтения этих ссылок:

Я придумал следующие изменения, внесенные в наш сервер windows 2k8.

  • рег добавить HKLM \ System \ CurrentControlSet \ Services \ HTTP \ Parameters/об MaxConnections/т REG_DWORD/d +1000000/ф
  • рег добавить HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters/v TcpTimedWaitDelay/т REG_DWORD/d 30/е
  • рег добавить HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0/об MaxConcurrentThreadsPerCPU/т REG_DWORD/d 0/f
  • рег добавить HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0/v MaxConcurrentRequestsPerCPU/t REG_DWORD/d 30000/f
  • appcmd.exe set apppool "[имя пула приложений]"/queueLeng го: 65535
  • appcmd.exe набор конфигурации/раздел: serverRuntime/appConcurrentRequestLimit: 100000
  • рег добавить HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters/об MaxUserPort/т REG_DWORD/d 65534/ф
  • рег добавить HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters/v MaxFreeTcbs/t REG_DWORD/d 2000/f
  • reg добавить HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Параметры/v MaxHashTableSize/t REG_DWORD/d 2048/f reg add HKLM \ System \ CurrentControlSet \ Services \ InetInfo \ Parameters/v MaxPoolThreads/t REG_DWORD/d 80/f
  • appcmd set config/section: processMode л/requestQueueLimit: 100000/фиксация: МАШИНА

Я не знаю, если все изменения были необходимы или оптимальны, но с некоторыми Quik tesing против тестового сервера, мы achived более 30k выполняющихся связей и 5k запросов в секунду , Не удалось пойти дальше, потому что у меня закончились клиентские машины для запуска тестов.