Metodologie per il test delle prestazioni di un collegamento WAN

11

Abbiamo un paio di nuovi collegamenti Ethernet a 1 Gbps a percorso differenziato tra località distanti circa 200 miglia. Il "client" è una nuova macchina ragionevolmente potente (HP DL380 G6, dual E56xx Xeons, 48GB DDR3, R1 coppia di dischi SAS 10krpm da 300GB, W2K8R2-x64) e anche il "server" è una macchina abbastanza decente (HP BL460c G6 , doppi E55xx Xeons, 72 GB, coppia R1 di dischi SAS 10krpm da 146 GB, HBA FC Emulex 4Gbps a doppia porta collegata a due Cisco MDS9509, quindi su HP EVA 8400 dedicato con dischi FC 128 x 450 GB 15krpm, RHEL 5,3-x64).

Usando SFTP dal client stiamo vedendo solo circa 40 Kbps di throughput usando file di grandi dimensioni (> 2 GB). Abbiamo eseguito test da "altri server locali" a server e vediamo circa 500 Mbps tramite gli switch locali (Cat 6509s), faremo lo stesso sul lato client, ma è ancora un giorno.

Quali altri metodi di test useresti per dimostrare ai fornitori di link che il problema è loro?

networking performance sftp

— Chopper3
fonte

Mi piacerebbe anche sapere una risposta a questa. La prossima settimana la nostra linea in affitto a 100 Mbit verrà installata :)

— Tom O'Connor,

come dice user37899 - i risultati sarebbero apprezzati.

— pQd

Nessun aggiornamento? Sono curioso di sapere come questo risulta.

— Kyle Brandt,

Ho battuto "abbastanza male" i fornitori di link (ironicamente fanno parte della stessa organizzazione per cui lavoro!) - non sono ancora tornati da noi.

— Chopper3

1

Ah va bene, e comunque, se riesci a capire perché ottengo 7 voti per serverfault.com/questions/134467/… e 1 per questo, vorrei saperlo ;-)

— Kyle Brandt

10

Accordare un elefante:
questo potrebbe richiedere l'ottimizzazione, probabilmente non il problema qui come dice pQd. Questo tipo di collegamento è noto come "Long, Fat Pipe" o elefante (vedi RFC 1072 ). Poiché si tratta di una grossa pipa gigabit che va oltre una distanza (in questo caso la distanza è davvero tempo / latenza), la finestra di ricezione tcp deve essere grande (vedere il volume 1 illustrato TCP / IP, sezione Estensioni TCP per le immagini).

Per capire quale deve essere la finestra di ricezione, si calcola il prodotto di ritardo della larghezza di banda:

Bandwidth * Delay = Product

Se esiste una latenza di 10 MS, questa calcolatrice stima che si desideri una finestra di ricezione di circa 1,2 MByte. Possiamo fare noi stessi il calcolo con la formula sopra:

echo $(( (1000000.00/.01)/8  )) 
12500000

Quindi potresti voler eseguire un dump di pacchetti per vedere se il ridimensionamento della finestra di tcp (l'estensione TCP che consente finestre più grandi) sta avvenendo correttamente per ottimizzare questo una volta che hai capito quale sia il grosso problema.

Window Bound:
se questo è il problema, che si è associati alla dimensione della finestra senza ridimensionamento, mi aspetterei i seguenti risultati se non è presente alcun ridimensionamento della finestra e vi è una latenza di circa 200 ms indipendentemente dalla dimensione del tubo:

Throughput = Recieve Window/Round Trip Time

Così:

echo $(( 65536/.2 ))
327680 #Bytes/second

Per ottenere i risultati che stai vedendo, dovrai solo risolvere la latenza, che sarebbe:

RTT = RWIN/Throughput

Quindi (per 40 kByte / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Controlla la mia matematica, e questi ovviamente non includono tutto il protocollo / intestazione overhead)

— Kyle Brandt
fonte

Sai che mi sono sentito un po 'in colpa per averti "sorpreso" temporaneamente sul rappresentante l'altra settimana, e il motivo è a causa di quanto dannatamente buone le tue risposte - e BOOM! usi persino una shell per fare i tuoi calcoli, non il Mac Calculator.app da 1,5 MB che faccio! :) Grazie.

— Chopper3

1

Hai anche delle buone risposte, e mi piace il fatto che io abbia qualcuno a cui sono vicino in rappresentanza, migliora un po 'il gioco :-) Query google veloce mi ricorda che hai risposto anche alle mie domande: serverfault.com/questions/107263/ ... . Apprezzo davvero molto gli utenti attivi che cercano di far "accadere" questa community. Ma grazie per il complemento!

— Kyle Brandt,

Anche a me, non c'è niente che mi piace di più che sapere che abbiamo aiutato qualcuno che sentiva di essere da solo con un problema frustrante - a parte il formaggio ovviamente. Detto questo, lo odio anche quando riceviamo domande formate male, hai sentito la mia domanda su SO podcast 82? anche una maglietta SF gratuita!

— Chopper3

Ascolto la maggior parte dei podcast ma ne ho perso uno, tornerò indietro e lo verificherò (probabilmente questo fine settimana).

— Kyle Brandt,

Mi dispiace per quel pQd, in realtà ho sempre letto il tuo nick come PDQ come in PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40kbps è molto basso [fino al punto in cui sospetterei convertitori multimediali difettosi / disadattamento duplex [ma hai gigabit quindi non c'è posto per half duplex!] Ecc]. devono esserci perdite di pacchetti o jitter molto elevato.

iperf è il primo strumento che mi viene in mente per misurare la produttività disponibile. correre da un lato

iperf -s

e dall'altro:

iperf -t 60 -c 10.11.12.13

quindi è possibile scambiare i ruoli client / server, utilizzare -d per duplex ecc. eseguire mtr tra le due macchine prima di iniziare il test e vedere quali perdite di latenza / pacchetto si hanno sul collegamento inutilizzato e come cambiano durante il trasferimento dei dati.

ti piacerebbe vedere: jitter molto piccolo e nessuna perdita di pacchetti fino a quando il collegamento è saturo al 90-qualcosa per cento della sua capacità.

iperf per * nix e vinci , leggi qui e qui a riguardo.

mtr per * nix e vinci .

— PQD
fonte

Sappiamo che il collegamento è composto da 6 collegamenti 1000-base-zx, quindi ci sarà sicuramente la latenza introdotta da tutto ciò che si ripete, ma anche così sono sorpreso dal fatto che tu sia basso, ottimo suggerimento sulla cosa iperf da parte del modo, avevo completamente dimenticato che esistesse!

— Chopper3

per favore pubblica i tuoi risultati!

— Unix Janitor,

1

tracepath può mostrare problemi di routing tra i due siti.

iperf, ttcp e bwping possono darti informazioni utili.

sai come viene eseguito il provisioning di questo link da 1 GB? stai ponticellando o instradando su questo link? Qual è il tuo SLA per il link? potresti essere plasmato dal tuo fornitore di link?

se ricevi solo 40kbs, allora c'è un problema serio, sei sicuro che non sia un link da 1 MB piuttosto che un link da 1 GB / s. Probabilmente scoprirai che la velocità del collegamento non è quella che pensi :-)

— Il bidello Unix
fonte

Grazie per la tua risposta, è un collegamento in fibra monomodale a ponte multisegmento dedicato, non c'è nessuna modellatura in quanto è solo L2 fino in fondo - oh e lo spero quindi non è un collegamento da 1 Mbps, non con i soldi che costa :)

— Chopper3

1

se il bridging alla LAN, ovvero nessun routing da nessuna parte, le trasmissioni di rete sprecheranno capacità di collegamento, vero per 1 GB sarà una piccola frazione, ma un servizio di rete mal funzionante potrebbe appiattire il collegamento. Presumo che questi ponti siano fuori dal tuo controllo. Questi interruttori possono essere sovraccarichi o essere soggetti a latenza molto elevata. Alta latenza significa bassa larghezza di banda.

— The Unix Janitor

@ user37899 - un'elevata latenza non deve significare una larghezza di banda ridotta, ma richiede un'ottimizzazione ... comunque - quanta latenza si può ottenere su 200 miglia - se le cose vanno bene - non più di 3-10ms. arp [o altro] trasmesso sul collegamento gigabit è probabilmente una frazione molto piccola dell'intera capacità disponibile.

— pQd

1

Se ci sono trasmissioni di rete a un livello tale da influire sulle prestazioni del collegamento, allora sospetto che avresti avuto problemi di prestazioni interne molto prima dell'arrivo di questa nuova linea e te ne sarei accorto.

— joeqwerty,

@pQd stavo davvero parlando di una tempesta di trasmissione.

— Unix Janitor,

0

RFC 2544 o Y.156sam

Questi sono test di rete che vengono effettuati per dimostrare lo SLA da parte del corriere. IPERF e simili non sono metodi di test di rete verificabili.

— Ansel Gaddy
fonte