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

Question

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

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

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

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

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

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

Спасибо.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

• IIS 7.0 503 errors with generic handler (.ashx) implementing IHttpAsyncHandler
• http://blogs.technet.com/b/winserverperformance/archive/2008/07/25/tuning-windows-server-2008-for-php.aspx
• http://smallvoid.com/article/winnt-tcpip-max-limit.html
• http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rprf_plugin.html
• http://support.microsoft.com/kb/820129
• http://msdn.microsoft.com/en-us/library/ee37705(BTS.10).aspx
• http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx

Я придумал следующие изменения, внесенные в наш сервер 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 запросов в секунду , Не удалось пойти дальше, потому что у меня закончились клиентские машины для запуска тестов.