Prestazioni di SignalR

Articolo
07/13/2023

Avviso

Questa documentazione non è per la versione più recente di SignalR. Esaminare ASP.NET Core SignalR.

Questo argomento descrive come progettare, misurare e migliorare le prestazioni in un'applicazione SignalR.

Versioni software usate in questo argomento

Visual Studio 2013

.NET 4.5

SignalR versione 2

Versioni precedenti di questo argomento

Per informazioni sulle versioni precedenti di SignalR, vedere Versioni precedenti di SignalR.

Domande e commenti

Lasciare commenti e suggerimenti su come è piaciuta questa esercitazione e ciò che è possibile migliorare nei commenti nella parte inferiore della pagina. Se si hanno domande che non sono direttamente correlate all'esercitazione, è possibile pubblicarli nel forum ASP.NET SignalR o StackOverflow.com.

Per una presentazione recente sulle prestazioni e sul ridimensionamento di SignalR, vedere Ridimensionamento del Web in tempo reale con ASP.NET SignalR.

In questo argomento sono incluse le sezioni seguenti:

Considerazioni relative alla progettazione
Ottimizzazione del server SignalR per le prestazioni
Risoluzione dei problemi relativi alle prestazioni
Uso dei contatori delle prestazioni di SignalR
Uso di altri contatori delle prestazioni
Altre risorse

Considerazioni relative alla progettazione

Questa sezione descrive i modelli che possono essere implementati durante la progettazione di un'applicazione SignalR, per garantire che le prestazioni non vengano impedite generando traffico di rete non necessario.

Limitazione della frequenza dei messaggi

Anche in un'applicazione che invia messaggi ad alta frequenza (ad esempio un'applicazione di gioco in tempo reale), la maggior parte delle applicazioni non deve inviare più di alcuni messaggi al secondo. Per ridurre la quantità di traffico generato da ogni client, un ciclo di messaggi può essere implementato che le code e invia messaggi non più frequentemente di una frequenza fissa, ovvero fino a un determinato numero di messaggi verranno inviati ogni secondo, se sono presenti messaggi in tale intervallo di tempo da inviare. Per un'applicazione di esempio che limita i messaggi a una determinata frequenza (sia dal client che dal server), vedere High-Frequency Realtime with SignalR.

Riduzione delle dimensioni dei messaggi

È possibile ridurre le dimensioni di un messaggio SignalR riducendo le dimensioni degli oggetti serializzati. Nel codice del server, se si invia un oggetto contenente proprietà che non devono essere trasmesse, impedire la serializzazione di tali proprietà usando l'attributo JsonIgnore . I nomi delle proprietà vengono archiviati anche nel messaggio; i nomi delle proprietà possono essere abbreviati usando l'attributo JsonProperty . L'esempio di codice seguente illustra come escludere una proprietà da inviare al client e come abbreviare i nomi delle proprietà:

Codice del server .NET che illustra l'attributo JsonIgnore per escludere i dati da inviare al client e l'attributo JsonProperty per ridurre le dimensioni dei messaggi

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
    [JsonProperty("l")]
    public double Left { get; set; }
    [JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
    [JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

Per mantenere la leggibilità/gestibilità nel codice client, i nomi delle proprietà abbreviati possono essere ricompressi ai nomi descrittivi dell'utente dopo la ricezione del messaggio. Nell'esempio di codice seguente viene illustrato un possibile modo per eseguire il mapping dei nomi abbreviati a quelli più lunghi, definendo un contratto di messaggio (mapping) e usando la funzione per applicare il reMap contratto alla classe di messaggi ottimizzata:

Codice JavaScript lato client che esegue il mapping dei nomi di proprietà abbreviati a nomi leggibili

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

I nomi possono essere abbreviati nei messaggi dal client al server, usando lo stesso metodo.

Ridurre il footprint di memoria , ovvero la quantità di memoria usata per il messaggio, dell'oggetto messaggio può anche migliorare le prestazioni. Ad esempio, se l'intervallo completo di un oggetto int non è necessario, è short possibile usare o byte .

Poiché i messaggi vengono archiviati nel bus di messaggi nella memoria del server, la riduzione delle dimensioni dei messaggi può anche risolvere i problemi di memoria del server.

Ottimizzazione del server SignalR per le prestazioni

Le impostazioni di configurazione seguenti possono essere usate per ottimizzare il server per migliorare le prestazioni in un'applicazione SignalR. Per informazioni generali su come migliorare le prestazioni in un'applicazione ASP.NET, vedere Miglioramento delle prestazioni ASP.NET.

Impostazioni di configurazione di SignalR

DefaultMessageBufferSize: per impostazione predefinita SignalR conserva 1000 messaggi in memoria per hub per ogni connessione. Se vengono usati messaggi di grandi dimensioni, questo può creare problemi di memoria che possono essere risolti riducendo questo valore. Questa impostazione può essere impostata nel Application_Start gestore eventi in un'applicazione ASP.NET o nel Configuration metodo di una classe di avvio OWIN in un'applicazione self-hosted. Nell'esempio seguente viene illustrato come ridurre questo valore per ridurre il footprint di memoria dell'applicazione per ridurre la quantità di memoria usata dal server:

Codice del server .NET in Startup.cs per ridurre le dimensioni predefinite del buffer dei messaggi
```
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Any connection or hub wire up and configuration should go here
        GlobalHost.Configuration.DefaultMessageBufferSize = 500;
        app.MapSignalR();
    }
}
```

Impostazioni di configurazione IIS

Numero massimo di richieste simultanee per applicazione: l'aumento del numero di richieste IIS simultanee aumenterà le risorse del server disponibili per la gestione delle richieste. Il valore predefinito è 5000; per aumentare questa impostazione, eseguire i comandi seguenti in un prompt dei comandi con privilegi elevati:
```
cd %windir%\System32\inetsrv\
appcmd.exe set config /section:system.webserver/serverRuntime 
        /appConcurrentRequestLimit:10000
```
ApplicationPool QueueLength: numero massimo di richieste che Http.sys code per il pool di applicazioni. Quando la coda è completa, le nuove richieste ricevono una risposta "Service Unavailable" 503. Il valore predefinito è 1000.

Ridurre la lunghezza della coda per il processo di lavoro nel pool di applicazioni che ospita l'applicazione conserva le risorse di memoria. Per altre informazioni, vedere Gestione, Ottimizzazione e Configurazione dei pool di applicazioni.

impostazioni di configurazione ASP.NET

Questa sezione include le impostazioni di configurazione che possono essere impostate nel aspnet.config file. Questo file viene trovato in una delle due posizioni, a seconda della piattaforma:

%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET impostazioni che possono migliorare le prestazioni di SignalR includono quanto segue:

Numero massimo di richieste simultanee per CPU: l'aumento di questa impostazione può ridurre i colli di bottiglia delle prestazioni. Per aumentare questa impostazione, aggiungere l'impostazione di configurazione seguente al aspnet.config file:
```
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>
```
Limite della coda richiesta: quando il numero totale di connessioni supera l'impostazione maxConcurrentRequestsPerCPU , ASP.NET inizierà a limitare le richieste usando una coda. Per aumentare le dimensioni della coda, è possibile aumentare l'impostazione requestQueueLimit . A tale scopo, aggiungere l'impostazione di configurazione seguente al processModel nodo in config/machine.config (anziché aspnet.config):
```
<processModel autoConfig="false" requestQueueLimit="250000" />
```

Risoluzione dei problemi relativi alle prestazioni

Questa sezione descrive i modi per trovare colli di bottiglia delle prestazioni nell'applicazione.

Verifica dell'uso di WebSocket

Anche se SignalR può usare un'ampia gamma di trasporti per la comunicazione tra client e server, WebSocket offre un vantaggio significativo sulle prestazioni e deve essere usato se il client e il server lo supportano. Per determinare se il client e il server soddisfano i requisiti per WebSocket, vedere Trasporto e fallback. Per determinare quale trasporto viene usato nell'applicazione, è possibile usare gli strumenti per sviluppatori del browser ed esaminare i log per visualizzare il trasporto usato per la connessione. Per informazioni sull'uso degli strumenti di sviluppo del browser in Internet Explorer e Chrome, vedere Trasporti e fallback.

Uso dei contatori delle prestazioni di SignalR

Questa sezione descrive come abilitare e usare i contatori delle prestazioni SignalR, trovati nel Microsoft.AspNet.SignalR.Utils pacchetto.

Installazione di signalr.exe

I contatori delle prestazioni possono essere aggiunti al server usando un'utilità denominata SignalR.exe. Per installare questa utilità, seguire questa procedura:

In Visual Studio selezionare Strumenti>Gestione pacchetti>NuGet Gestire pacchetti NuGet per la soluzione
Cercare signalr.utils e selezionare Installa.
Accettare il contratto di licenza per installare il pacchetto.
SignalR.exe verrà installato in <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Installazione di contatori delle prestazioni con SignalR.exe

Per installare i contatori delle prestazioni signalR, eseguire SignalR.exe in un prompt dei comandi con privilegi elevati con il parametro seguente:

SignalR.exe ipc

Per rimuovere i contatori delle prestazioni di SignalR, eseguire SignalR.exe in un prompt dei comandi con privilegi elevati con il parametro seguente:

SignalR.exe upc

Contatori delle prestazioni signalR

Il pacchetto utilità installa i contatori delle prestazioni seguenti. I contatori "Totale" misurano il numero di eventi dall'ultimo riavvio del pool di applicazioni o del server.

Metriche di connessione

Le metriche seguenti misurano gli eventi di durata della connessione che si verificano. Per altre informazioni, vedere Informazioni e gestione degli eventi di durata della connessione.

Connessioni connesse
Connessioni riconnesse
Connessioni disconnesse
Connessioni correnti

Metriche per i messaggi

Le metriche seguenti misurano il traffico del messaggio generato da SignalR.

Messaggi di connessione ricevuti totale
Messaggi di connessione inviati totale
Messaggi di connessione ricevuti/sec
Messaggi di connessione inviati/sec

Metriche del bus di messaggio

Le metriche seguenti misurano il traffico tramite il bus di messaggio SignalR interno, la coda in cui vengono inseriti tutti i messaggi SignalR in ingresso e in uscita. Un messaggio viene pubblicato quando viene inviato o trasmesso. Un Sottoscrittore in questo contesto è una sottoscrizione nel bus di messaggi; questo deve essere uguale al numero di client più il server stesso. Un ruolo di lavoro allocato è un componente che invia i dati alle connessioni attive; un ruolo di lavoro occupato è uno che invia attivamente un messaggio.

Messaggi del bus di messaggio ricevuti totale
Messaggi del bus di messaggio ricevuti/sec
Messaggi del bus di messaggio pubblicati totale
Messaggi del bus di messaggio pubblicati/sec
Sottoscrittori del bus di messaggio correnti
Sottoscrittori del bus di messaggio Totale
Sottoscrittori del bus di messaggio/sec
Ruoli di lavoro allocati del bus di messaggio
Ruoli di lavoro occupati dal bus di messaggio
Argomenti correnti del bus di messaggio

Metriche di errore

Le metriche seguenti misurano gli errori generati dal traffico dei messaggi SignalR. Gli errori di risoluzione dell'hub si verificano quando non è possibile risolvere un metodo hub o hub. Gli errori di chiamata dell'hub sono eccezioni generate quando si richiama un metodo hub. Gli errori di trasporto sono errori di connessione generati durante una richiesta o una risposta HTTP.

Errori: Tutto il totale
Errori: All/Sec
Errori: Totale risoluzione hub
Errori: Risoluzione hub/sec
Errori: Totale chiamata hub
Errori: chiamata all'hub/sec
Errori: Totale trasporto
Errori: Trasporto/sec

Metriche di scalabilità

Le metriche seguenti misurano il traffico e gli errori generati dal provider di scaleout. Un flusso in questo contesto è un'unità di scalabilità usata dal provider di scaleout; si tratta di una tabella se viene usata SQL Server, un argomento se viene usato il bus di servizio e una sottoscrizione se viene usato Redis. Ogni flusso garantisce operazioni di lettura e scrittura ordinate; un singolo flusso è un potenziale collo di bottiglia di scala, quindi il numero di flussi può essere aumentato per ridurre il collo di bottiglia. Se vengono usati più flussi, SignalR distribuisce automaticamente i messaggi (partizioni) in questi flussi in modo da garantire che i messaggi inviati da qualsiasi connessione specificata siano in ordine.

L'impostazione MaxQueueLength controlla la lunghezza della coda di invio di scaleout gestita da SignalR. Impostandolo su un valore maggiore di 0 verranno inseriti tutti i messaggi in una coda di invio da inviare uno alla volta al backplane di messaggistica configurato. Se la dimensione della coda supera la lunghezza configurata, le chiamate successive da inviare avranno esito negativo immediatamente con un'eccezione InvalidOperationException fino a quando il numero di messaggi nella coda è minore dell'impostazione. La coda è disabilitata per impostazione predefinita perché i backplan implementati in genere hanno la propria accodamento o il controllo del flusso. Nel caso di SQL Server, il pool di connessioni limita in modo efficace il numero di invii in qualsiasi momento.

Per impostazione predefinita, viene usato solo un flusso per SQL Server e Redis, cinque flussi vengono usati per il bus di servizio e la coda è disabilitata, ma queste impostazioni possono essere modificate tramite la configurazione in SQL Server e il bus di servizio:

Codice del server .NET per la configurazione del numero di tabelle e della lunghezza della coda per SQL Server backplane

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

Codice del server .NET per la configurazione del conteggio degli argomenti e la lunghezza della coda per il backplane del bus di servizio

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
TopicCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

Un flusso di buffering è uno che ha immesso uno stato di errore; quando il flusso si trova nello stato di errore, tutti i messaggi inviati al backplane avranno esito negativo immediatamente fino a quando il flusso non è più in errore. La lunghezza della coda di invio è il numero di messaggi pubblicati ma non ancora inviati.

Messaggi del bus di messaggio di scalabilità ricevuti/sec
Scaleout Stream Total
Flussi scaleout aperti
Buffering dei flussi di scalabilità
Errori di scalabilità totale
Errori di scalabilità/sec
Lunghezza della coda di invio scaleout

Per altre informazioni sulla misurazione di questi contatori, vedere Scaleout SignalR con bus di servizio di Azure.

Uso di altri contatori delle prestazioni

I contatori delle prestazioni seguenti possono essere utili anche per monitorare le prestazioni dell'applicazione.

Memoria

Byte di memoria CLR .NET\# in tutti gli heaps (per w3wp)

ASP.NET

ASP.NET\Richieste correnti
ASP.NET\Accodato
ASP.NET\Rifiutato

CPU

Informazioni sul processore\Tempo processore

TCP/IP

TCPv6/Connections stabilita
TCPv4/Connections stabilita

Servizio Web

Servizio Web\Connessioni correnti
Servizio Web\Connessioni massime

Threading

Blocchi e thread CLR .NET\# dei thread logici correnti
Blocchi E thread CLR .NET di thread fisici correnti

Risorse aggiuntive

Per altre informazioni sul monitoraggio e l'ottimizzazione delle prestazioni ASP.NET, vedere gli argomenti seguenti:

Share via

Prestazioni di SignalR

Versioni software usate in questo argomento

Versioni precedenti di questo argomento

Domande e commenti

Considerazioni relative alla progettazione

Limitazione della frequenza dei messaggi

Riduzione delle dimensioni dei messaggi

Ottimizzazione del server SignalR per le prestazioni

Risoluzione dei problemi relativi alle prestazioni

Verifica dell'uso di WebSocket

Uso dei contatori delle prestazioni di SignalR

Installazione di signalr.exe

Installazione di contatori delle prestazioni con SignalR.exe

Contatori delle prestazioni signalR

Uso di altri contatori delle prestazioni

Risorse aggiuntive

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive