2008-09-23 16 views
3

nous sommes un client qui a besoin d'obtenir des messages interactifs à partir d'un serveur, des clients qui sont distribués dans le monde entier derrière toutes sortes de pare-feu avec toutes sortes de ports fermés. La seule chose sur laquelle nous pouvons compter est le port HTTP 80 (et HTTPS 443).problème de performance IIS essayant de mettre en œuvre un protocole comme XMPP

La conception est essentiellement calqués sur XMPP (le protocole Jabber), en utilisant notre client et IIS. Le client émet 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; sinon, après une temporisation, la connexion est fermée avec une réponse "sans données". Le client rouvre immédiatement la communication.

Eh bien, théoriquement. En réalité, IIS ne peut pas gérer plus de 100 requêtes simultanées. D'autres sont toutes en file d'attente, et il peut y avoir un décalage de plusieurs minutes entre "connected" et IIS reconnaissant que le client a appelé. environ la moitié du temps que le client expire sans aucune réponse du serveur (le délai d'expiration du client est cinq minutes plus long que celui du serveur).

Le POST fonctionne toujours. Les autres données diffusées sur le même serveur Web fonctionnent. Les services Web sur le même serveur fonctionnent. Ceci est 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 envisager pour résoudre ce problème?

Merci.

Répondre

3

Je pense que vous utilisez les limites de pool d'unités d'exécution ASP.NET plutôt que celles d'IIS. Regardez dans la création d'un gestionnaire HTTP asynchrone (IHttpAsyncHandler) comme quand ils bloquent/attendent qu'ils ne lient pas le pool de threads (ils utilisent des ports d'achèvement à la place).

Mise à jour: Nous sommes tombés sur cette récemment qui semble d'accord avec ma façon de penser: CodeProject: Scalable COMET Combined with ASP.NET

1

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

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

0

XMPP n'a jamais été conçu pour des applications de haute performance. Les messages doivent traverser la pile entière vers la couche application, et il y a beaucoup d'analyse XML. Avez-vous envisagé d'utiliser une autre norme en plus de XMPP?

+2

"XMPP n'a jamais été conçu pour des applications haute performance." Je ne sais pas ce que vous entendez par «haute performance», mais il a été conçu pour bavarder et il le fait extrêmement bien, ce que demande le PO. ejabberd, par exemple, peut gérer des centaines de milliers de requêtes simultanées. –

1

De la boîte, windows a besoin de tweeking. J'ai dû implémenter un serveur de comètes dans asp.net et j'ai rencontré des défauts par défaut.Après avoir lu ces liens:

Je suis venu avec les modifications suivantes qui ont été apportées à notre serveur Windows 2k8.

  • reg ajouter HKLM \ System \ CurrentControlSet \ Services \ HTTP \ Parameters/v MaxConnections/t REG_DWORD/d 1000000/f
  • reg ajouter HKLM \ System \ CurrentControlSet \ Services \ TcpIp TcpTimedWaitDelay \ Parameters/v/t REG_DWORD/d 30/f
  • reg ajouter HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0/v MaxConcurrentThreadsPerCPU/t REG_DWORD/d 0/f
  • reg ajouter HKLM \ SOFTWARE \ Microsoft \ ASP.NET \ 2.0.50727.0/v MaxConcurrentRequestsPerCPU/t REG_DWORD/d 30000/f
  • appcmd.exe définie par l'application "[nom du pool d'applications]"/queueLeng th: 65535
  • config/section de réglage appcmd.exe: serverRuntime/appConcurrentRequestLimit: 100000
  • reg ajouter HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters/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 ajoutez HKLM \ System \ CurrentControlSet \ Services \ InetInfo \ Paramètres/v MaxPoolThreads/t REG_DWORD/d 80/f
  • appcmd set config/section: processMode l/requestQueueLimit: 100000/commettras: MACHINE

Je ne sais pas si tous les changements étaient nécessaires ou optimale, mais avec un peu Quik tesing sur un serveur de test, nous achived sur 30k exécution des connexions et 5k requêtes par seconde . Impossible d'aller plus loin parce que je n'ai plus de machines clientes pour lancer les tests.