Jan 082011
 

tarOvvero scp VS tar+ssh VS rsync+ssh VS tar+netcat

In un precedente articolo in cui mostravo alcuni utilizzi di tar, ho fatto l’esempio di come utilizzarlo per spostare grosse moli di dati tra due computer, ma molte persone hanno affermato che è meglio, o quantomeno preferiscono usare un Rsync, altri ancora preferiscono usare netcat. Io resto dell’idea che un tar+ssh è più veloce di un rsync+ssh è quindi giusto fare una prova “sul campo” e vedere qualche numero.

Per le prove userò 2 computer collegati sulla mia rete domestica, entrambi sono collegati con wi-fi al mio router, penso che il collo di bottiglia sarà (per le prova con ssh) la CPU di laptop1 (Centrino 1.5 GHz).

Quindi abbiamo

laptop1: centrino 1500 — ip 192.168.0.10
laptop2: Intel Core2 Duo CPU 2.20GHz — ip 192.168.0.2

Misurazione di banda

Per avere una prima idea di quello che potevo ottenere ho misurata la banda tra i due PC con iperf, ho fatto 10 run standard per ottenere un valore medio che fosse realistico.

Sul client ho lanciato

~ # iperf -c 192.168.0.2

Sul server:

~ # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40530
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-12.1 sec  3.47 MBytes  2.40 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40531
[  4]  0.0-12.7 sec  3.94 MBytes  2.61 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40536
[  4]  0.0-12.3 sec  3.99 MBytes  2.73 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40538
[  4]  0.0-11.4 sec  3.65 MBytes  2.68 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40540
[  4]  0.0-19.5 sec  4.01 MBytes  1.72 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40541
[  4]  0.0-11.3 sec  3.67 MBytes  2.71 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 40545
[  4]  0.0-11.5 sec  3.82 MBytes  2.78 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 37802
[  4]  0.0-10.2 sec   888 KBytes   715 Kbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 37812
[  4]  0.0-12.4 sec  1.59 MBytes  1.08 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.10 port 37814
[  4]  0.0-11.9 sec  3.88 MBytes  2.74 Mbits/sec

Quindi abbiamo una media di 2.2 Mbits/sec non tanto, ma a noi interessa fare dei confronti relativi, quindi non è importante la velocità.

Primo test

Copierò dal laptop1 al laptop2 la directory /var/lib/dpkg che contiene 7105 files che occupano 61 MB. Visto che Rsync compara le due directory cancellerò tutto alla fine di ogni run.

Questo è lo script che ho utilizzato per misurare le velocità:

#!/bin/bash
 
for i in `seq 1 10`; do time scp -qrp /var/lib/dpkg 192.168.0.2:/test/copy/; 
ssh 192.168.0.2 rm -fr /test/copy/dpkg; done
 
echo "End scp"
 
for i in `seq 1 10`; do time rsync -ae ssh /var/lib/dpkg 192.168.0.2:/test/copy/; 
ssh 192.168.0.2 rm -fr /test/copy/dpkg; done
 
echo "End rsync"
 
for i in `seq 1 10`; do time tar -cf - /var/lib/dpkg |ssh 192.168.0.2 tar -C /test/copy/ -xf - ; 
ssh 192.168.0.2 "rm -fr /test/copy/*"; done

Per Netcat ho usato:

Sulla macchina ricevente i dati (laptop2):

# nc -l -p 7000 | tar x

E sulla macchina che spediva i dati (laptop1):

# cd /var/lib/dpkg
# time tar cf - * | nc 192.168.0.2 7000

Questi i risultati ottenuti (in secondi):
dati

Per ogni metodo ho scartato i 2 risultati migliori ed i 2 peggiori ed ho fatto una media una media dei 6 rimanenti.

scp: 246 seconds
rsync+ssh: 130 seconds
tar+ssh: 149 seconds
tar+netcat: 131 seconds

Quindi con i miei computer (e la mia rete) il metodo migliore per trasferire i files sembra essere effettivamente un rsync con ssh.

Secondo test

Non soddisfatto dei risultati ottenuti ho eseguito esattamente gli stessi test su due server collegati via gigabit ethernet.
Per qualche errore non sono riuscito a misurare i tempi del netcat, funzionava ma non usciva correttamente e così non sono riuscito a misurarne i tempi (che erano comunque molto bassi).

Rsync+ssh e tar+ssh completavano tutto il lavoro correttamente in meno di un secondo ho così incluso i tempi al centesimo di secondo.

dati2

Conclusioni

Sinceramente mi aspettavo una classifica del tipo: netcat > tar+ssh > rsync+ssh > scp, e puntualmente sono stato smentito dalle prove sui miei PC.

Test simili fatti su un altro blog hanno risultati molto simili a quelli che mi aspettavo, quindi le mie deduzioni sono:

1) Non usate mai un scp “liscio” è il peggior metodo che potete usare
2) A seconda della rete e dei Computer che avete a disposizione avrete risultati diversi con rsync e tar.
3) Su reti veloci il tar+ssh sembra essere leggermente più performante, mi aspetto che con netcat che toglie la cifratura (comparato ad ssh) si ottengano risultati ancora migliori.
4) Rsync può lavorare in maniera incrementale quindi ha fortissimi vantaggi di usabilità rispetto agli altri metodi se sapete in partenza che l’operazione dovrà essere eseguita più volte (esempio fare dei sync piu’ volte al giorno tra due siti).

Popular Posts:

Flattr this!

  4 Responses to “Il miglior modo per spostare dati”

  1. I did some similar tests with large datasets (300 GB +) and found tar over ssh the be the most reliable for the speed. One thing I did notice, adding options to the ssh command can really have an impact on performance.

    If you are doing file transfers on a local lan and are not too concerned about full encryption. You may want to add: -c arcfour

    Host Key Checking causes considerable pauses in establishing connections. Once again if you are on a lan, you may want to add: -o StrictHostKeyChecking=no

    And one other note, if you do publickey authentication adding: o PreferredAuthentications=publickey can also cut down on the time it takes to establish a connection.

    For example:
    tar -cpf – * | ssh -2 -4 -c arcfour -o StrictHostKeyChecking=no -o PreferredAuthentications=publickey -lroot ${REMOTE_HOST} tar -C ${REMOTE_DIRECTORY}/ -xpf -”

    Thanks for the interesting read….
    Chad

  2. Thanks for doing this test. Debian and peers steered me to tar, sftp and finally rsync. The man page for rsync in Debian is excellent and contains many common case examples. Thanks to your test, I now know that my prefered method, rsync, is also one of the fastest.

    I like rsync to much that I’ve started using it as an improved copy for local files. Grsync is a nice GUI front end that works well with frequent but irregularly timed syncs because it stores “sessions”.

    I’m not sure of the syntax you are using for “rsync + ssh.” The manual advises:

    rsync -avz source:/local_files/ target:/remote_files

    I was under the impression that a single colon invoked ssh by default. “man rsh” brings up the ssh man page. Compression, the -z, might dog slow cpus, but it might be faster than your 802.11B.

    Another advantage to rsync is easy resume capability. I’m not sure how the other methods would handle a break in commuication.

  3. Not all that surprising.

    SSH really isn’t all that CPU-consuming. Sure, it’s encryption, but symmetric encryption (which is used after the initial authentication) can be quite fast even in software. For instance, try “dd if=/dev/zero bs=1048576 | openssl enc -blowfish -k somepass > /dev/null”. On my machine, it performs at 91,2 MB/s, almost enough to fully saturate a 1GB-line with payload, and faster than many disks even in sequential read.

    Regarding rsync vs. tar, rsync is optimized for efficient network-usage, not efficient disk-usage. In your particular case, it sounds like many small files was the challenge. While rsync is usually the winner in partial updates, it has a strong disadvantage in the first run, since it scans the directory on both machines first to determine which files to transfer.

    Also, if network is the bottleneck and not CPU, you can optimize your tar-example with compression, for instance bzip2 or xz/lzma. My /var/lib/dpkg went from 90MB to 13 using bzip2, with a throughput of 6.1mbit, so adding a -j to your tar-line it might improve your low-bandwidth-example even more than rsync if you want to prove a point.

    Also, rsync uses compression by default, so disabling it /might/ improve performance in the high-bandwidth-case.

  4. Unfortunately currently fast chipers for ssh are unavailable, then for fast network and fast hard drives, ssh is much slower than raw tcp transfering.
    Is it possible running rsync by netcat transport ?

Leave a Reply to twitter Cancel reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)

*