IIS Leistungsproblem versucht, ein XMPP-ähnliches Protokoll zu implementieren


3

Wir haben einen Client, der interaktive Nachrichten von einem Server erhalten muss, von Clients, die auf der ganzen Welt hinter allen Arten von Firewalls mit allen Arten von geschlossenen Ports verteilt sind. Das einzige, auf das wir uns verlassen können, ist der HTTP-Port 80 (und HTTPS 443).

Das Design basiert im Wesentlichen auf XMPP (dem Jabber-Protokoll) und verwendet unseren Client und IIS. Der Client gibt GET-Anforderungen an einen .NET-Handler aus; Der Handler hält die Anfrage für eine Weile offen und sucht nach Nachrichten. Wenn Nachrichten ankommen, werden sie sofort an den Client gesendet; Wenn nicht, wird nach einer Zeitüberschreitung die Verbindung mit einer "No-Data" -Antwort geschlossen. Der Client öffnet die Kommunikation sofort wieder.

Nun, theoretisch.

Was zuerst passiert, ist zuerst, IIS kann nicht mehr als etwa 100 gleichzeitige Anfragen - andere sind alle in der Warteschlange, und es kann ein paar Minuten Verzögerung zwischen "verbunden" und IIS erkennen, dass der Client angerufen. Etwa die Hälfte der Zeit, die der Client ohne Antwort vom Server läuft (das Client-Timeout ist fünf Minuten länger als das des Servers).

POST funktioniert immer. Andere Daten, die auf demselben Webserver bereitgestellt werden, funktionieren. Webdienste auf demselben Server funktionieren. Dies ist eine Out-of-the-Box-Installation unter Windows 2K3 Server.

Gibt es eine Konfigurationsoption, die wir vermissen, oder gibt es noch etwas, das ich untersuchen sollte?

Danke.

3

Ich denke, dass Sie ASP.NET-Thread-Pool-Grenzen statt IIS schlagen. Suchen Sie nach einem asynchronen HTTP-Handler (IHttpAsyncHandler), wenn sie blockieren/warten, dass sie den Thread-Pool nicht binden (sie verwenden stattdessen Completion-Ports).

aktualisieren: kam vor kurzem in das, dass mit meinem Denken zu stimmen scheint: CodeProject: Scalable COMET Combined with ASP.NET


1

Wenn IIS nicht Ihren Anforderungen entspricht, sollten Sie einen anderen Webserver wie Apache (mit Mod_mono) oder LightTPD auswählen.

BTW, können Sie XMPP durch HTTP unter Verwendung XMPP Over BOSH tunneln. Keine Notwendigkeit, ein benutzerdefiniertes Protokoll zu erfinden.


0

XMPP wurde nie für Hochleistungsanwendungen ausgelegt. Die Nachrichten müssen den gesamten Stack bis zur Anwendungsebene durchqueren, und es wird viel XML analysiert. Haben Sie darüber nachgedacht, einen anderen Standard als XMPP zu verwenden?

+2

"XMPP wurde nie für Hochleistungsanwendungen entwickelt." Ich weiß nicht, was Sie unter "Höchstleistung" verstehen, aber es wurde zum Chatten entwickelt und macht das sehr gut, und darum geht es dem OP. Beispielsweise kann ejabberd Hunderttausende von simultanen Anfragen bearbeiten. 21 jan. 112011-01-21 16:33:38


1

Out-of-the-Box, Windows braucht einige Tweeking. Ich musste einen Kometenserver in asp.net implementieren und stieß auf einige dumme Standardwerte.Nach dem Lesen dieser Links:

Ich habe die folgenden Änderungen an unserem Windows 2k8 Server vorgenommen.

  • 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 HKLM \ Software \ Microsoft \ ASP.NET fügen \ 2.0.50727.0/v MaxConcurrentRequestsPerCPU/t REG_DWORD/d 30000/f
  • appcmd.exe set apppool "[App-Pool-Name]"/queueLeng th: 65535
  • appcmd.exe set config/section: serverRuntime/appConcurrentRequestLimit: 100000
  • reg HKLM \ System hinzufügen \ CurrentControlSet \ Services \ Tcpip \ Parameters/v MaxUserPort/t REG_DWORD/d 65534/f
  • reg Fügen Sie HKLM \ System \ CurrentControlSet \ Services \ TcpIp \ Parameters/v hinzu. MaxFreeTcbs/t REG_DWORD/d 2000/f
  • reg hinzufügen HKLM \ System \ CurrentControlSet \ Dienste \ TcpIp \ Parameters/MaxHashTableSize/t REG_DWORD/d 2048/f reg hinzufügen HKLM \ System \ CurrentControlSet \ Dienste \ InetInfo \ Parameters/v MaxPoolThreads/t REG_DWORD/d 80/f
  • appcmd set config/Abschnitt: processMode l/requestqueue: 100000/commit: MACHINE

Ich weiß nicht, ob alle Änderungen erforderlich waren oder optimal, aber mit etwas Quik Tesing vor einem Test-Server, wir achived über 30k Ausführung Verbindungen und 5k Anfragen pro Sekunde . Konnte nicht weiter gehen, weil mir die Client-Rechner ausgingen, um die Tests auszuführen.