Problema di prestazioni IIS nel tentativo di implementare un protocollo simile a XMPP
-
02-07-2019 - |
Domanda
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.
Soluzione
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
Altri suggerimenti
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.
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.
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?