SignalR hub self-host o no?

Question

Sto lavorando a un progetto in cui un hub SignalR avvia 12 thread a esecuzione ridotta (nuova discussione()). Ogni thread riporta al client al completamento tramite websockets. I thread non sono ad alta intensità di CPU, ma ottengono alcune informazioni da altri servizi web.

Ora il mio dilemma è questo: dovrei creare un'applicazione hub signalR autonoma ospitata che viene eseguita come servizio o dovrei semplicemente includere l'hub nel mio progetto asp.net MVC?

Qual è il rendimento migliore?

Answer 1

Se le prestazioni sono un problema, utilizzerei Thread Pool e non nuovo Thread.

E ospiterò è un servizio di Windows, perché mi darebbe più controllo in termini di risorse da allocare ai thread.

Answer 2

Il modo corretto per farlo NET 4.5 è poi farlo singolo asincrono filettato.

ASP.Net should NEVER be creating new threads. Esistono enormi implicazioni sulle prestazioni quando si utilizzano esplicitamente i thread con ASP.Net.

Inoltre, è necessario sapere che i thread sono un'astrazione di risorse CPU limitate (si è notato tanto affermando che i thread non hanno un utilizzo intensivo della CPU). In .net 4.5 in poi, questo dovrebbe dirvi che NON dovreste usare i thread. Instead, in this case you should be using a threadless I/O api to call your webservices. Ti consiglierei di utilizzare il modello TAP (alias asyncawait), che in pratica è .net 4.5.

Ciò dovrebbe consentire di ridimensionare con una macchina moderatamente potente migliaia di richieste simultanee.

Se si dispone di tutto questo, utilizzando TAP, ASP.Net MVC/IIS funzionerà bene con la massiccia parallelizzazione e "threading". In questo caso, vorrei sconsigliare l'uso di un servizio Windows, poiché si avrà una migliore stabilità con IIS come bootstrapper (gestione della durata e riavvio del servizio in caso di morte).