Panoramica delle prestazioni TCP/IP

Note

Questo articolo è incluso in una serie in 3 parti. È possibile esaminare la parte 2: problemi di rete sottostanti relativi alle prestazioni TCP/IP e parte 3: problemi noti relativi alle prestazioni TCP/IP.

Le prestazioni di Transmission Control Protocol/protocollo IP (TCP/IP) offrono un confronto. Il confronto deve essere eseguito con endpoint identici in termini di hardware, percorso di rete e sistema operativo. Le prestazioni reali sono diverse perché sono coinvolti più fattori che possono causare un collo di bottiglia. Questi fattori sono spesso la rete sottostante, la progettazione di TCP e la velocità di trasmissione effettiva delle operazioni di I/O di archiviazione.

Altre informazioni sull'ottimizzazione delle prestazioni per impostare la configurazione con le migliori prestazioni per gli endpoint.

La regolazione automatica della finestra di ricezione TCP è una funzionalità definita dall'applicazione usata per aumentare le prestazioni della connessione per usare la larghezza di banda nelle reti a latenza elevata. Ad esempio, se il protocollo TCP è configurato per l'uso del livello di ottimizzazione automatica su normale e se l'applicazione dispone di un buffer sufficiente definito per la finestra TCP, il sistema operativo ridimensiona il tcp al massimo rapidamente. Questa funzionalità, tuttavia, è progettata per reti a latenza più elevate. Per le reti a bassa latenza, non esiste un requisito di questo tipo, perché non ci saranno molti segmenti in tempo reale (ad esempio, nell'infrastruttura di rete).

Per le reti a latenza elevata con una finestra TCP che non viene ridimensionata al massimo contemporaneamente, esistono algoritmi come CUBIC, NewReno e Compound TCP per determinare il prodotto con ritardo della larghezza di banda e ridimensionare di conseguenza la finestra. Il sistema operativo Windows assegna un algoritmo di congestione a ogni socket creato.

Le impostazioni TCP sono predefinite in Windows 10. Usare il cmdlet Get-NetTCPSettings per ottenere le impostazioni TCP e usare il cmdlet Get-NetTCPConnection per visualizzare le proprietà di connessione TCP, ad esempio l'indirizzo IP locale o remoto, la porta locale o remota e lo stato della connessione.

Ecco i suggerimenti per migliorare la velocità effettiva:

• Assicurarsi che non siano presenti problemi di rete sottostanti (perdita di pacchetti).
• Abilitare le proprietà avanzate della scheda di interfaccia di rete per le funzionalità relative alle prestazioni (ad esempio frame Jumbo, RSS/VMQ, funzionalità di offload e RSC), tranne se è presente un problema di compatibilità di rete sottostante o per la risoluzione dei problemi.
• Assicurarsi che TCP sia configurato per l'uso normale del livello di ottimizzazione automatica.
• Usare l'analisi di Monitor prestazioni per assicurarsi che non siano presenti colli di bottiglia della CPU o dell'archiviazione.
• Selezionare le funzionalità di sicurezza in base ai requisiti effettivi delle organizzazioni.
• Creare una baseline.

Strumento di test per la velocità effettiva TCP

Per ottenere la massima velocità effettiva possibile per un determinato hardware, è necessario ottimizzare i fattori di prestazioni. Assicurarsi che non siano presenti problemi di rete sottostanti (perdita di pacchetti). Usare lo strumento NTttcp.exe o ctsTraffic.exe per testare la velocità effettiva. Vedere Strumenti per le prestazioni per carichi di lavoro di rete.

Colli di bottiglia per la velocità effettiva TCP

Non usare monitoraggio di rete o acquisire i log a livello di pacchetto di rete durante i test della velocità effettiva TCP. I filtri di monitoraggio NDIS (Network Driver Interface Specification) aggiungono un ritardo per il mittente e i ricevitori ogni volta che viene registrato un pacchetto. Questa operazione richiede risorse CPU e genera molte operazioni di I/O di archiviazione. Le prestazioni diminuiscono quando vengono acquisiti i log a livello di pacchetto perché il protocollo TCP sta tentando di eseguire il ripristino dalla perdita di pacchetti.

L'aggiunta di sicurezza presenta problemi di costi e prestazioni specifici. I protocolli di sicurezza, ad esempio Internet Protocol Security (IPsec) presentano requisiti di overhead e elaborazione aggiuntivi. Confrontare la protezione dei dati con l'integrità dei dati, è consigliabile preferire la modalità di integrità di IPsec per un costo di elaborazione inferiore. Il software di sicurezza ha un costo enorme anche per l'elaborazione dei pacchetti, che causerà output più lenti.

Se le prestazioni testate non arrivano alle aspettative, prendere i log come definito nei contatori delle prestazioni correlati alla rete.

Dopo aver verificato i problemi di prestazioni TCP, controllare i protocolli associati al livello superiore, ad esempio protocolli di file system (SMB) o NFS (Network File System). Questi protocolli richiedono risorse del processore e I/O del disco. La velocità lenta è causata da un driver o da un hardware difettoso, da una coda DPC (High DeFerred Procedure Call) o/e da operazioni di I/O su disco lente. Individuare il componente del sistema operativo che causa un numero elevato di CONTROLLER di dominio è complesso perché richiede un'analisi usando la registrazione xperf/Windows Performance Recorder (WPR) (CPU). Trovare problemi di lentezza correlati al disco è relativamente più semplice. Per altre informazioni, vedere Analisi e ottimizzazione delle prestazioni del disco.

Durante il test, è possibile modificare le applicazioni di test (applicazioni client e server) per usare più thread con valori di buffer sufficientemente elevati per raggiungere la velocità effettiva massima. Tuttavia, ciò potrebbe non riflettere le condizioni effettive perché il numero di thread e buffer che ogni chiamata API può usare è limitato in base alla programmazione. Inoltre, il protocollo AMB (Application Layer Protocol, SMB o Common Internet File System) ha un proprio buffer e ottimizzazione (Ottimizzazione delle prestazioni per file server o SMB: Guida alla risoluzione dei problemi). Se l'applicazione non funziona come previsto per la baseline, rivolgersi a uno specialista dell'applicazione per trovare il collo di bottiglia.

Come creare una baseline

Per confrontare la velocità effettiva corrente, è necessario creare una baseline di prestazioni. Per comprendere meglio la rete, creare la linea di base all'inizio della distribuzione.

Una linea di base è costituita dai punti principali seguenti:

• Reti di origine e di destinazione
• Latenza e conteggio hop tra queste reti
• Funzionalità e configurazione del processore/interfaccia
• Intervallo di tempo dei test (ore lavorative/ore non lavorative/ore di punta)
• Versioni del sistema operativo
• Push di velocità effettiva e pull della velocità effettiva

Note

Creare la linea di base con gli stessi modelli server (stesso numero di schede di interfaccia di rete e capacità del processore) per mantenere quasi uguale la potenza di elaborazione.

Controllare il buffer e tenere traccia del numero di sessioni di trasporto create dagli strumenti di test. Quattro sessioni di trasporto TCP simultanee possono valutare l'utilizzo della CPU in modo uniforme con RSS abilitato.

Ecco i passaggi per misurare la velocità effettiva e creare una baseline:

1. Scaricare lo strumento ctsTraffic . Ecco una descrizione di alcuni parametri dello strumento ctsTraffic.

   Parametro	Descrizione
   -listen:<IP/*>	Questa opzione viene usata per l'ascolto delle porte nei server. Se * viene specificato, lo strumento ctsTraffic è in ascolto su tutti gli indirizzi IP disponibili nel computer. Ad esempio: -listen:*.
   -target:<IP>	Questa opzione viene usata nei client e specifica l'indirizzo IP del server in cui è in esecuzione ctsTraffic.exe ed è in ascolto. Ad esempio: -target:192.168.1.10.
   -pattern:pull	Per impostazione predefinita, lo strumento CtsTraffic usa il modello Push. Ciò significa che i dati vengono inviati dal client al server. Quando questa opzione viene usata sia sul client che sul server, i dati vengono ricevuti nel client. Non usare questa opzione durante l'esecuzione di un test push.
   -connections:<num>	Questa opzione specifica il numero di connessioni TCP. I socket TCP verranno creati contemporaneamente dal client. Otto vengono comunemente usate come code RSS nelle schede di rete di livello intermedio sono 8. Ad esempio: -connections:8.
   -iterations:<num>	Questa opzione specifica il numero moltiplicato di connessioni in -connections:. Ad esempio: -iterations:10. Con 10 iterazioni, il client tenterà 80 connessioni in totale. Se questa opzione non è specificata, il client continuerà a tentare 8 connessioni fino a 1000 connessioni.
   -statusfilename:<filename.csc>	Utilizzare questa opzione per scaricare l'opzione livello 1 della console in un .txt file compatibile con Microsoft Excel.
   -connectionfilename:<filename.csv>	Usare questa opzione per scaricare i dettagli dettagliato. Ad esempio, informazioni sul livello del socket, ad esempio il tempo impiegato da ogni socket per trasferire i dati. È possibile verificare se sono presenti errori o risoluzione dei problemi avanzati con questa opzione.
   -consoleverbosity:<0|1|2|3>	Questa opzione specifica la visualizzazione o l'output nel monitor durante l'esecuzione del test. Ad esempio: -consoleverbosity:1.

2. Aprire Monitoraggio risorse sul lato ricevente. Ad esempio, se si usa -pattern:pull, aprirlo nel client; in caso contrario, aprirlo nel server.

3. Avviare lo strumento ctsTraffic nel server ed eseguire il comando seguente:

   Ctstraffic.exe -listen:* -consoleverbosity:1 <-pattern:pull>
   

   

4. Avviare lo strumento ctsTraffic nel client ed eseguire il comando seguente:

   Ctstraffic.exe -target:<serverip> -consoleverbosity:1 <-pattern:pull> -connections:8 -iterations:10
   

   

5. Assicurarsi che i processori del lato ricevente vengano utilizzati uniformemente. In caso contrario, controllare il problema con RSS per scoprire quale non funziona come previsto.

   

6. Calcolare la velocità effettiva in bit al secondo in base al risultato sul client. Fare riferimento all'esempio nello screenshot seguente:

   

   In questo esempio la velocità effettiva è quasi 19 GB/s e viene calcolata come segue:

   (85.899.349.200 byte/36,678 secondi) * 8 = 18.735.885.097.33355 (bit al secondo)

Passaggi successivi

Altre informazioni sulla risoluzione dei problemi di prestazioni TCP/IP sulla rete sottostante