Scalatura SQL di Signalr: svantaggi dell'utilizzo di più flussi?

Question

Nella pagina SignalR Performance, possiamo leggere:

Un Flusso in questo contesto è un'unità di misura utilizzata dal ScaleOut fornitore; questa è una tabella se viene utilizzato SQL Server, un argomento se viene utilizzato il servizio Bus e una sottoscrizione se viene utilizzato Redis. Ogni stream garantisce le operazioni di lettura e scrittura ordinate ; un flusso singolo è un potenziale collo di bottiglia , quindi il numero di flussi può essere aumentato per aiutare a ridurre quel collo di bottiglia. Se vengono utilizzati più flussi, SignalR invierà automaticamente i messaggi (shard) attraverso questi flussi in un modo che assicura che i messaggi inviati da qualsiasi connessione siano in ordine.

Il conteggio corrente (. Es tabella in SQL) può essere impostato in questo modo:

var connectionString = "(your connection string)"; 
var config = new SqlScaleoutConfiguration(connectionString) { 
    TableCount = 3, 
    MaxQueueLength = 50 }; 
GlobalHost.DependencyResolver.UseSqlServer(config); 

Ma il TableCount è 1 per default in SQL ScaleOut. Se si tratta di un collo di bottiglia di scala, perché è 1 per impostazione predefinita? Cosa succede se l'ho impostato su 50?

La documentazione non fornisce alcun indizio per decidere quale valore dare. Dovrei impostarlo su 1, 3, 10, 1000? Quali sono i pro e i contro di un grande valore? Aumenta semplicemente la latenza?

Answer 1

Dalla documentazione:

https://msdn.microsoft.com/en-us/library/microsoft.aspnet.signalr.sqlscaleoutconfiguration(v=vs.118).aspx

TableCount
Ottiene o imposta il numero di tabelle per memorizzare i messaggi in Utilizzando più tabelle riduce il conflitto di blocco e può aumentare il throughput.. Questo deve essere coerente tra tutti i nodi nella web farm. L'impostazione predefinita è 1.