Problème de performances IIS lors de la tentative d'implémentation d'un protocole de type XMPP

Question

nous avons un client qui doit recevoir des messages interactifs d'un serveur, de clients répartis dans le monde entier derrière tous les types de pare-feu avec tous les types de ports fermés. La seule chose sur laquelle nous pouvons compter est le port HTTP 80 (et HTTPS 443).

La conception est essentiellement basée sur XMPP (protocole Jabber), à l’aide de notre client et de IIS. Le client envoie des requêtes GET à un gestionnaire .NET. le gestionnaire maintient la demande ouverte pendant un moment à la recherche de messages. Si des messages arrivent, ils sont immédiatement envoyés au client. Si ce n'est pas le cas, la connexion est fermée après un délai d'attente avec un message "no-data". réponse. Le client rouvre immédiatement la communication.

Eh bien, théoriquement.

Ce qui se passe réellement, c’est d’abord, IIS ne peut pas traiter plus de 100 demandes simultanées - d’autres sont toutes en file d’attente et il peut s'écouler plusieurs minutes de retard entre "connecté" et "connecté". et IIS reconnaissant que le client a appelé. Deuxièmement, environ la moitié du temps du client expire sans aucune réponse du serveur (le délai d'expiration du client est supérieur de cinq minutes à celui du serveur).

POST fonctionne toujours. Les autres données servies sur le même serveur Web fonctionnent. Les services Web sur le même serveur fonctionnent. Il s’agit d’une installation prête à l'emploi sur Windows 2K3 Server.

Existe-t-il une option de configuration qui nous manque ou y a-t-il autre chose que je devrais examiner pour remédier à cela?

Merci.

Answer 1

Je pense que vous atteignez les limites du pool de threads ASP.NET, plutôt que celles d'IIS. Cherchez à créer un gestionnaire HTTP asynchrone ( IHttpAsyncHandler ), car lorsqu'ils bloquent / attendent, ils n'attachent pas le pool de threads (ils utilisent plutôt des ports d'achèvement).

Mise à jour : je suis récemment tombé sur cette idée qui semble correspondre à ma pensée: CodeProject: COMET évolutif combiné à ASP.NET

Answer 2

Si IIS ne répond pas à vos besoins, vous devez choisir un autre serveur Web tel que Apache (avec Mod_mono ) ou LightTPD .

BTW, vous pouvez tunneler XMPP via HTTP en utilisant XMPP sur BOSH . Pas besoin d'inventer un protocole personnalisé.

Answer 3

Hors de la boîte, Windows a besoin d’être modifié. J'ai dû implémenter un serveur de comète dans asp.net et j'ai rencontré quelques défauts stupides. Après avoir lu ces liens:

• Erreurs IIS 7.0 503 avec un gestionnaire générique (.ashx) implémentant 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

Les modifications suivantes ont été apportées à notre serveur Windows 2k8.

• reg ajoutez HKLM \ System \ CurrentControlSet \ Services \ HTTP \ Paramètres / v MaxConnections / t REG_DWORD / d 1000000 / f
• reg ajoutez HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Paramètres / v TcpTimedWaitDelay / t REG_DWORD / d 30 / f
• reg ajoutez HKLM \ LOGICIEL \ Microsoft \ ASP.NET \ 2.0.50727.0 / v MaxConcurrentThreadsPerCPU / t REG_DWORD / d 0 / f
• reg ajoutez HKLM \ LOGICIEL \ Microsoft \ ASP.NET \ 2.0.50727.0 / v MaxConcurrentRequestsPerCPU / t REG_DWORD / d 30000 / f
• appcmd.exe définir apppool " [nom du pool d'applications] " / queueLength: 65535
• appcmd.exe set config / section: serverRuntime / appConcurrentRequestLimit: 100000
• reg ajoutez HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Paramètres / v MaxUserPort / t REG_DWORD / d 65534 / f
• reg ajoutez HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Paramètres / v MaxFreeTcbs / t REG_DWORD / d 2000 / f
• reg ajoutez HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Paramètres / v MaxHashTableSize / t REG_DWORD / d 2048 / f reg add ajouter HKLM \ System \ CurrentControlSet \ Services \ InetInfo \ Parameters / v MaxPoolThreads / t REG_DWORD / d 80 / f
• appcmd set config / section: processModel / requestQueueLimit: 100000 / commit: MACHINE

Je ne sais pas si tous les changements étaient nécessaires ou optimaux, mais avec quelques interrogations sur un serveur de test, nous avons obtenu plus de 30 000 connexions exécutées et 5 000 requêtes par seconde. Je n’ai pas pu aller plus loin car j’ai manqué de machines clientes pour exécuter les tests.

Answer 4

XMPP n’a jamais été conçu pour des applications hautes performances. Les messages doivent traverser l’ensemble de la pile jusqu’à la couche d’application, ce qui nécessite beaucoup d’analyses XML. Avez-vous envisagé d’utiliser une norme autre que XMPP?