Problema di prestazioni IIS nel tentativo di implementare un protocollo simile a XMPP

Question

abbiamo un client che deve ricevere messaggi interattivi da un server, da client che sono distribuiti in tutto il mondo dietro tutti i tipi di firewall con tutti i tipi di porte chiuse. L'unica cosa su cui possiamo fare affidamento è la porta HTTP 80 (e HTTPS 443).

Il design è sostanzialmente modellato su XMPP (il protocollo Jabber), usando il nostro client e IIS. Il client invia richieste GET a un gestore .NET; il gestore tiene aperta la richiesta per un po 'alla ricerca di messaggi. Se arrivano messaggi, vengono immediatamente inviati al client; in caso contrario, dopo un timeout la connessione viene chiusa con un "nessun dato" risposta. Il client riapre immediatamente la comunicazione.

Beh, teoricamente.

Quello che sta realmente accadendo è il primo, IIS non può gestire più di circa 100 richieste simultanee - gli altri sono tutti in coda e può esserci un ritardo di alcuni minuti tra " connesso " e IIS riconoscono che il client ha chiamato. In secondo luogo, circa la metà del tempo di timeout del client senza alcuna risposta dal server (il timeout del client è di cinque minuti più lungo di quello del server).

POST funziona sempre. Altri dati forniti sullo stesso server Web funzionano. I servizi Web sullo stesso server funzionano. Questa è un'installazione immediata sul server Windows 2K3.

C'è un'opzione di configurazione che ci manca o c'è qualcos'altro che dovrei guardare per affrontarlo?

Grazie.

Answer 1

Penso che tu stia colpendo i limiti del pool di thread ASP.NET, piuttosto che quelli di IIS. Cerca di creare un gestore HTTP asincrono ( IHttpAsyncHandler ) poiché quando bloccano / attendono non stanno legando il pool di thread (usano invece le porte di completamento).

Aggiornamento : di recente mi sono imbattuto in questo che sembra concordare con il mio pensiero: CodeProject: COMET scalabile combinato con ASP.NET

Answer 2

Se IIS non soddisfa i tuoi requisiti, devi scegliere un altro server Web come Apache (con Mod_mono ) o LightTPD .

A proposito, puoi eseguire il tunneling di XMPP tramite HTTP utilizzando XMPP Over BOSH . Non è necessario inventare un protocollo personalizzato.

Answer 3

Fin dall'inizio, Windows ha bisogno di qualche modifica. Ho dovuto implementare un server di comete in asp.net e mi sono imbattuto in alcune sciocche impostazioni predefinite. Dopo aver letto questi link:

• Errori IIS 7.0 503 con gestore generico (.ashx) implementando 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/ it-it / 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

Ho trovato le seguenti modifiche apportate al nostro server 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 imposta apppool " [nome pool app] " / 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

Non so se tutte le modifiche fossero necessarie o ottimali, ma con alcune criticità su un server di prova, abbiamo ottenuto oltre 30k di connessioni in esecuzione e 5k richieste al secondo. Impossibile andare oltre perché ho esaurito le macchine client da cui eseguire i test.

Answer 4

XMPP non è mai stato progettato per applicazioni ad alte prestazioni. I messaggi devono attraversare l'intero stack fino al livello dell'applicazione e sono presenti numerosi analisi XML. Hai preso in considerazione l'utilizzo di altri standard oltre a XMPP?