Prestazioni di SignalR (SignalR 1.x)

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.

Per una presentazione recente sulle prestazioni e il 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 ostacolate generando traffico di rete non necessario.

Frequenza dei messaggi di limitazione

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 pochi messaggi al secondo. Per ridurre la quantità di traffico generata da ogni client, è possibile implementare un ciclo di messaggi che accoda e invia messaggi non più frequentemente di una frequenza fissa, ovvero fino a un determinato numero di messaggi verrà inviato 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 (Frequenza elevata in tempo reale con 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 che contiene proprietà che non devono essere trasmesse, impedire la serializzazione di tali proprietà tramite l'attributo JsonIgnore . I nomi delle proprietà vengono archiviati anche nel messaggio; I nomi delle proprietà possono essere abbreviati usando l'attributo JsonProperty . Nell'esempio di codice seguente viene illustrato come escludere una proprietà dall'invio al client e come abbreviare i nomi delle proprietà:

Codice server .NET che illustra l'attributo JsonIgnore per escludere i dati dall'invio 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à o la manutenibilità nel codice client, è possibile modificare il mapping dei nomi delle proprietà abbreviati ai nomi descrittivi dopo la ricezione del messaggio. Nell'esempio di codice riportato di seguito viene illustrato un modo possibile per eseguire il mapping dei nomi abbreviati a quelli più lunghi, definendo un contratto di messaggio (mapping) e usando la reMap funzione per applicare il contratto alla classe messaggio ottimizzata:

Codice JavaScript sul lato client che riemapa i nomi delle proprietà abbreviati in 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 anche nei messaggi dal client al server, usando lo stesso metodo.

La riduzione del 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 int oggetto non è necessario, è possibile usare o shortbyte .

Poiché i messaggi vengono archiviati nel bus di messaggi in memoria 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 ottenere prestazioni migliori 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 mantiene 1000 messaggi in memoria per ogni hub per ogni connessione. Se si usano messaggi di grandi dimensioni, è possibile che si verifichino 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. L'esempio seguente illustra 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 Global.asax per ridurre le dimensioni predefinite del buffer dei messaggi
```
protected void Application_Start(object sender, EventArgs e)
{
    GlobalHost.Configuration.DefaultMessageBufferSize = 500;
}
```

Impostazioni di configurazione di 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
```

impostazioni di configurazione ASP.NET

Questa sezione include le impostazioni di configurazione che possono essere impostate nel aspnet.config file. Questo file si trova 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 al file l'impostazione aspnet.config di configurazione seguente:
```
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>
```
Limite coda richieste: quando il numero totale di connessioni supera l'impostazione maxConcurrentRequestsPerCPU , ASP.NET avvierà la limitazione delle 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 Trasporti e fallback. Per determinare quale trasporto viene usato nell'applicazione, è possibile usare gli strumenti di sviluppo del browser ed esaminare i log per vedere quale trasporto viene 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 di SignalR, disponibili 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> Gestionepacchetti>NuGet Gestisci 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 dei contatori delle prestazioni con SignalR.exe

Per installare i contatori delle prestazioni di 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 di 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.

Totale messaggi di connessione ricevuti
Totale messaggi di connessione inviati
Messaggi di connessione ricevuti/sec
Messaggi di connessione inviati/sec

Metriche del bus di messaggi

Le metriche seguenti misurano il traffico attraverso il bus di messaggi 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 sul bus di messaggi; 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.

Totale messaggi ricevuti del bus di messaggi
Messaggi del bus di messaggi 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. Per impostazione predefinita, viene usato un solo flusso, ma questo può essere aumentato tramite la configurazione in SQL Server e il bus di servizio. 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 CLR .NETAndThreads# di thread logici correnti
Blocchi CLR .NETAnd Threads# di thread fisici correnti

Risorse aggiuntive

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

Condividi tramite

Prestazioni di SignalR (SignalR 1.x)

Considerazioni relative alla progettazione

Frequenza dei messaggi di limitazione

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 dei contatori delle prestazioni con SignalR.exe

Contatori delle prestazioni di SignalR

Uso di altri contatori delle prestazioni

Risorse aggiuntive

Commenti e suggerimenti

Risorse aggiuntive