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

Question

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

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

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

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

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

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

Спасибо.

Answer 1

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

Обновление : Недавно я столкнулся с этим, который, кажется, совпадает с моим мнением: CodeProject: Масштабируемый COMET в сочетании с ASP.NET

Answer 2

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

• Ошибки IIS 7.0 503 с универсальным обработчиком (.ashx), реализующим 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.

• reg add HKLM \ System \ CurrentControlSet \ Services \ HTTP \ Parameters / v MaxConnections / t REG_DWORD / d 1000000 / f
• reg add HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters / v TcpTimedWaitDelay / t REG_DWORD / d 30 / f
• reg add HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0 / v MaxConcurrentThreadsPerCPU / t REG_DWORD / d 0 / f
• reg add HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0 / v MaxConcurrentRequestsPerCPU / t REG_DWORD / d 30000 / f
• appcmd.exe set apppool "[имя пула приложений]" / queueLength: 65535
• appcmd.exe set config / section: serverRuntime / appConcurrentRequestLimit: 100000
• reg add HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters / v MaxUserPort / t REG_DWORD / d 65534 / f
• reg add HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters / v MaxFreeTcbs / t REG_DWORD / d 2000 / f
• reg add HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters / 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: processModel / requestQueueLimit: 100000 / commit: MACHINE

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

Answer 3

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

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

Answer 4

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