Perché il download multi-thread è più veloce del thread singolo?


13

C'è un file di grandi dimensioni nel mio server. Trovo che il download multi thread possa ottenere 20 Mb, ma un thread singolo può ottenere 10 Mbps, qualcuno può spiegarlo?


Più thread che servono la stessa connessione TCP o più thread ciascuno con connessioni TCP separate? Stai anche dicendo che il server è multithread, o il client è multithread, o entrambi?
Spiff

Risposte:


14

Di solito questo è perché da qualche parte tra te e l'altro server c'è un firewall che limita ogni flusso HTTP a 10 Mbps. Quando si utilizza il multi-thread, si ottiene 2x 10 Mb (uno per ogni thread).


1
Uso FTP e non ci sono limiti sul mio server
perché il

@why: forse è il tuo ISP a limitare ogni connessione a 10 Mbps? Puoi ottenere di più da questo in un tester di velocità?
André Paramés,

4

Ciò è dovuto al ping tra te e il server e la dimensione del pacchetto / dimensione della finestra tcpip utilizzata dal tuo software di download.

Fondamentalmente, se hai un ping di 100ms sul server e richiedi pacchetti di 100kb, puoi ottenere solo 10 pacchetti al secondo usando 1 connessione, anche se la tua velocità di internet è infinita.


Non è necessario ACK per ciascun pacchetto, fintanto che il ricevitore sta svuotando il suo buffer a una velocità ragionevole, il mittente dovrebbe essere in grado di pomparli continuamente.
André Paramés,

Giusto. Ma anche con un buffer da 256kb, il ping provoca ancora un
notevole

3

TCP funziona al meglio quando "mantieni la pipe piena" - quando l'app di invio continua a inviare buffer abbastanza rapidamente da mantenere lo stack TCP del mittente costantemente fornito di dati in modo che possa sempre avere dati "in volo" sulla rete e quando il destinatario l'app continua a leggere dallo stack TCP del ricevitore abbastanza velocemente da non riempire mai la finestra TCP del ricevitore (di nuovo, quindi lo stack TCP mittente può sempre mantenere i dati "in volo" sulla rete).

Potrei immaginare un'app mittente a thread singolo scritta male che passa un buffer allo stack TCP, attende di sapere che è stato completamente bloccato e quindi passa un altro buffer. Ciò significa che una volta che la fine del primo buffer è "in volo" sulla rete, lo stack TCP di invio è affamato per i dati da inviare, il che significa che il tubo si scarica e non viene riempito fino a quando l'Ack non torna e l'app di invio gli passa un nuovo buffer.

Potrei anche immaginare un'app ricevente a thread singolo a scrittura scadente che non legge dallo stack TCP ricevente abbastanza velocemente e quindi si riempie i buffer dello stack TCP, il che significa che la finestra TCP si riempie, causando lo stack TCP di invio smettere di inviare fino a quando la finestra si apre alcuni. Aumentare le dimensioni della finestra TCP del destinatario può essere di aiuto, ma la vera soluzione a questo scopo è leggere i dati più velocemente.


Quindi, potrebbe non avere nulla a che fare con l'essere single thread?
Ape-inago,

@Ape-inago Certo, un'app a thread singolo ben scritta potrebbe mantenere la pipa piena, sì.
Spiff

2

Bene, probabilmente perché puoi trasferire così tanti dati su una sola connessione. Tuttavia, in un programma multi-thread puoi avere due connessioni che ricevono dati contemporaneamente e raddoppiano la quantità di informazioni che puoi ottenere. Ci sono alcune limitazioni a questo ad esempio la velocità del server da cui stai scaricando ... Tanto di cappello a chi ha scritto il downloader multi-thread, quelli non sono facili da scrivere.


1
perché è così difficile? Hai solo bisogno di allocare una singola sezione per ogni thread e lasciarlo scrivere nella sezione appropriata del file dei risultati. La fonte di axel mi sembra piuttosto semplice.
André Paramés,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.