Copia file multithread

Dipende da cosa è il fattore limitante, vero? Se il collo di bottiglia è il programma di utilità, quindi sicuro, l'esecuzione di più di una copia o l'utilizzo di più thread accelererà le cose. Se la rete è il fattore limitante, quindi l'aggiunta di più istanze dell'utilità non sarà di aiuto in quanto rimarrai bloccato al massimo X byte al secondo. In effetti potrebbe danneggiare perché hai il sovraccarico aggiuntivo di una seconda copia dell'app. Lo stesso con disk-IO. È possibile copiare solo alla velocità massima consentita dalla lettura e dalla scrittura su disco. Se questo è già il massimo, aggiungere copie non ti sarà di aiuto.

Quello che devi fare è testare per vedere qual è il collo di bottiglia e andare da lì.

In che modo il multithreading non aiuta:

Più thread che leggono simultaneamente dal disco del client o che inviano simultaneamente roba in rete non sono di alcuna utilità, poiché molto probabilmente esiste solo un percorso di comunicazione tra il client e il server, il client probabilmente leggerà i file da un singolo disco rigido e i file sono probabilmente scritti su un singolo disco rigido sul server. (Anche se il server ha RAID, farà qualche differenza, ma non molto.) Al contrario, come è già stato sottolineato, le prestazioni si degraderanno, perché ci sarà una ricerca costante tra i file letti parallelo sul client e ricerca costante tra i file scritti in parallelo sul server. Inoltre, i file potrebbero finire per essere archiviati in modo frammentato sul server.

Come il multithreading aiuterà:

Tuttavia, il multithreading può aiutare in un modo diverso: con solo due thread sul client, l'I / O del file può essere desincronizzato dall'I / O della rete. Ciò significa che il client può trasmettere simultaneamente un blocco di un file durante la lettura del blocco successivo dal suo disco. (Il server è già in grado di scrivere simultaneamente un blocco di un file sul disco mentre riceve il blocco successivo dalla rete.) Questo notevolmente accelera il processo di trasferimento, perché il client tenderebbe a mantenere o il canale di rete o il canale del disco (a seconda di quale sia più lento) saturo, invece di accedere a ciascuno alla volta, a intermittenza. Immagino che ogni utility di copia di file specializzata là fuori dovrebbe essere abbastanza intelligente per farlo, ma potrei sbagliarmi, quindi se "Robocopy" pubblicizza che fanno copia multi-thread, va bene, vai con quello.

EDIT: ho corretto il bit che avevo scritto su RAID.

EDIT: ho corretto il bit sulla richiesta di due thread sul server.

Immagino che la cosa più importante qui, dato che è quasi ovunque, è misura . Non hai alcun controllo su come funzionano queste utility, quindi saprai solo se lo stai facendo nel modo più veloce possibile se misurerai il throughput per vedere se è vicino al throughput pubblicizzato del tuo disco o della tua rete (qualunque sia il più piccolo .)

Durante la copia di molti file più piccoli, il multithreading può essere d'aiuto perché tendono a essere lacune nel trasferimento dei dati mentre il programma cerca le directory per il file successivo, aprendolo e recuperando i dati.

Il multithreading aiuterà anche quando il client e il server hanno entrambi la memorizzazione di dati paralleli come RAID o SSD: tutto ciò che funziona meglio con numeri di profondità della coda più alti.

Oltre a questo, spesso rallenta le cose. Ad esempio, facendo un singolo disco rigido leggere o scrivere due file contemporaneamente lo costringerà a cercare ripetutamente dal file 1 al file 2.

Lavoro per Data Expedition, Inc. che, come menzionato da Emmad, produce software commerciale per questo tipo di scenario. Trasferimento file multithread può avere dei benefici, ma devi capire attentamente quali sono le tue prestazioni i colli di bottiglia sono.

Qualsiasi percorso di rete avrà almeno decine di componenti hardware e software che i dati devono passare. Il più lento di tutti determinerà la tua velocità. Ma il modo in cui sposti i dati cambierà il modo in cui tali componenti comportarsi.

Un sacco di informazioni su questo qui: link

L'esecuzione di TCP paralleli può aiutare quando le singole velocità del TCP stanno scendendo molto al di sotto delle capacità della rete, del disco e della CPU.

Ma se stai considerando velocità di rete superiori a decine di megabit per in secondo luogo, i trasferimenti paralleli di dati riducono esponenzialmente l'I / O del disco a causa del thrashing del disco rigido. Può rapidamente cadere al punto in cui il disco l'accesso diventa molto più lento della capacità della rete. Scegliere il giusto la dimensione del blocco di lettura / scrittura può aiutare, ma ciò dipenderà dal particolare hardware. Ricorda inoltre che Windows XP / 2003 ha una memoria di paging pool molto limitata, che può renderlo instabile se la velocità supera i 200 megabit al secondo.

Il rovescio della medaglia, se la rete è più lenta di poche decine di megabit per in secondo luogo, quindi l'esecuzione di molti TCP paralleli può spingere la latenza fino al punto dove le sessioni individuali iniziano a rallentare o addirittura a far cadere le loro connessioni. Ancora una volta, è una questione di sperimentazione per scoprire quale sarà il livello del parallelismo lavoro per qualsiasi percorso e condizioni.

Quindi, la copia di file multithread può essere d'aiuto se si dispone di un percorso dati conosciuto e possibile prenditi il tempo necessario per mettere a punto il numero di sessioni parallele e l'I / O del disco. Ma richiede che tu ti risintonizzi ogni volta che le condizioni cambiano e possono esserlo dirompente se si esagera. Ecco perché abbiamo scelto di evitare il parallelo trasferimenti nel nostro software proprio come evitiamo il TCP.

Oltre a ciò che è stato detto, considera: - Ci deve essere un'attività sul client per creare i blocchi e un'altra sul server per rimetterli insieme come 1 file. Questo richiede un po 'di lavoro.

• Una cosa buona dei piccoli pezzi è che puoi inviare nuovamente parti di un file se il processo fallisce invece di inviare il file grande dappertutto.

• Considera la richiesta di una "pipe più grande" tra il tuo client e il server.

• Considera Zippare il file grande prima di inviarlo (non sono sicuro se ciò potrebbe essere d'aiuto in caso di file multimediali multipli poiché a volte sono già compressi).

• Considera l'utilizzo di un'utilità di trasferimento file commerciale come:

DataExp

Se stai parlando di un grosso file, il multithreading non ti sarà di grande aiuto. Sarai vincolato all'I / O, quindi l'uso di un singolo thread non rallenterà QUESTO upload in basso.

Tuttavia, ciò che si può fare è preoccuparsi del conflitto di risorse (supponendo che si stia scrivendo anche il server). Se stai gestendo il caricamento nella discussione che accetta anche ed elabora nuove richieste, altre richieste saranno in attesa. Finché si rimanda alla coda del selettore dopo aver letto un chunk dal socket e averlo scritto sul disco, si dovrebbe andare bene.

Fare ciò che suggerisci in modo ingenuo ucciderà il tuo throughput, il punto di strozzatura è I / O su disco e non sta preparando i file.

Suggerirò di usare un thread che riceve i file con cui lavorare e li accoda per la copia e quindi mantiene una copia sequenziale in corso su qualsiasi cosa nella coda; il thread del tuo fornitore è responsabile per far leggere i file in coda. In questo modo non stai battendo il file system sulle unità condivise e non stai facendo i file uno alla volta con gli spazi vuoti per preparare il prossimo, ti stai preparando e inviando contemporaneamente.

Il bonus è che c'è un solo punto di sincronizzazione in coda di cui preoccuparsi.

Invece di implementare il caricamento parallelo da soli, potresti prendere in considerazione i protocolli e gli strumenti esistenti. Per esempio. il protocollo ftp e lo strumento lftp (lftp può trasferire diversi file in parallelo).

Quindi è probabilmente molto più semplice e robusto usare gli script lftp o il controllo lftp dall'applicazione invece di implementare tutto da zero.

Tutto dipende da dove è il fattore limitante.

Il multithreading può aiutare se ci sono ritardi di andata e ritorno o altri gap nella trasmissione, e i thread aiutano a colmare le lacune.

Il multithreading potrebbe fare male se ha l'effetto di far muovere il disco avanti e indietro, cercando di mantenere tutti i thread forniti con i dati.

ecc.