[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ativar compactação de dados no fish://

Ronaldo Reis-Jr. wrote:


Em Sábado 20 Maio 2006 14:22, Marcos Vinicius Lazarini escreveu:


Ronaldo Reis-Jr. wrote:

ao invez de usar fish, tente sftp

Em ultimo caso vc pode deixar a compressão ligada por default no servidor


Agora comparar o sftp c/ o rsync é crueldade... :-)

--
Marcos



Marcos,

Blz
Testei com o sftp e ele é mais lento que o fish. Não entendo porque o rsync seria tão mais rápido, não estou usando via servidor rsync, mas sim via ssh, então acho que quem define a velocidade é o ssh, ou não? 

Mas vou tentar exemplificar melhor o ocorrido.
Tenho dois computadores chamados fasterix e mobilix conectados por um cabo de rede invertido. 

Algumas especificações que acho que podem ter haver com a questão:

fasterix:
Intel(R) Pentium(R) 4 CPU 1.70GHz
cache size      : 256 KB
Mem. RAM: 1 GB
Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 86)

mobilix:
Intel(R) Pentium(R) M processor 1.60GHz
cache size: 2048 KB
Mem. RAM: 512 MB
Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet


O dois com Debian/Testing sempre atualizado.
Todos os procedimentos de transferência foram realizados com o protocolo fish no kde. 

As velocidades foram:

mobilix <- fasterix [~10mb/s]
mobilix -> fasterix [~1.2mb/s]

fasterix <- mobilix [~3.7mb/s]
fasterix -> mobilix [~1.2mb/s]
As configurações do servidor ssh são iguais e não modificadas, ou seja, são as mesmas instaladas por default. 

A questões que ficam são:
Por a diferença tão grande entre as velocidades de download (<-) e de upload (->)?
Porque a diferença tão grande entre as velocidades de download (<-) dos dois computadores (10mb/s X 3.7mb/s) 

Porque esta diferença de download não se repete no upload?
O que fazer para melhorar a performance? Ativar a compactação de dados no servidor ssh? Como se faz? Ou ativar nos clientes?
Só para ver se ajuda, o mesmo teste usando o scp via terminal a partir do mobilix 

Velocidades de uploads:
[ronaldo@mobilix ~]$ scp Teste.mpg ronaldo@fasterix:./
Teste.mpg 100% 72MB 11.9MB/s 00:06 [ronaldo@mobilix ~]$ scp -C Teste.mpg ronaldo@fasterix:./ Teste.mpg 100% 72MB 5.5MB/s 00:13 [ronaldo@mobilix ~]$ scp Teste.mpg ronaldo@fasterix:./ Teste.mpg 100% 72MB 11.9MB/s 00:06 [ronaldo@mobilix ~]$ scp -C Teste.mpg ronaldo@fasterix:./ Teste.mpg 100% 72MB 5.1MB/s 00:14 
Velocidades de downloads:
[ronaldo@mobilix ~]$ scp ronaldo@fasterix:./Teste.mpg ./
Teste.mpg 100% 72MB 11.9MB/s 00:06 [ronaldo@mobilix ~]$ scp -C ronaldo@fasterix:./Teste.mpg ./ Teste.mpg 100% 72MB 3.1MB/s 00:23 [ronaldo@mobilix ~]$ scp ronaldo@fasterix:./Teste.mpg ./ Teste.mpg 100% 72MB 10.2MB/s 00:07 [ronaldo@mobilix ~]$ scp -C ronaldo@fasterix:./Teste.mpg ./ Teste.mpg 100% 72MB 3.3MB/s 00:22 Aí o mais estranho, pois o -C é para justamente para habilitar a compressão dos dados, desta forma eu esperaria que a transmissão de dados com -C fosse mais rápida, porém não foi isto que ocorreu. 

Ronaldo, vamos tentar esclarecer umas coisas.
o fish:// funciona atraves do ssh + scripts em perl na máquina remota (entre num diretório como /usr/share ou /usr/share/doc e veja com o top uns processos perl aparecendo e sumindo). Já o sftp:// utiliza direto o protocolo sftp (existe um comando sftp p/ os desavisados, muito semelhante ao ftp). A diferença de desempenho tbm está relacionada com a diferença de implementação.
Outra coisa, achei o arquivo que vc testou pequeno, pois transferiu em até menos de 10 segundos. Talvez um de + de 1 GB (p/ nao caber nada no cache) ou um de 300 MB (p/ caber no cache dos dois).
Os micros são +- rápidos e vc tá trabalhando proximo do limite de saturação da rede 100 Mbps (teóricos 12.5 MB/s). Mas pelos seus resultados, o uso de CPU deve estar bem alto - pois quando vc liga a compressão, a CPU não dá mais conta de comprimir nessa taxa e acaba segunrado a transmissão. Leia na manpage do ssh: 

[...]
The compression algorithm is the same used by gzip(1), and the ``level'' can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. 
[...]

deixe rolando uma transmissão e monitore a CPU com o top (ou com o htop)
Outra comentário é que no exemplo vc está tentando comprimir um .mpg, que não deve comprimir quase nada... então isso literalmente é esforço jogado fora. Se seus dados forem isso, mais um motivo p/ não usar compressão. 

Voltando...
O rsync usa muito I/O de disco e um bom tanto de CPU - se o disco de uma máquina for lento, isso pode atrasar todo o processo. Isso acontece justamente p/ se evitar transferir muitos dados que já foram transferidos atualmente... Muito bem dito pelo admin do kernel.org, o rsync "trades bandwidth for CPU horsepower" [1]
Já o unison (nunca usei) tem um trabalho extra que é justamente saber quem tem que mandar o que pra onde, e me parece q ele mandem uma série de informações num .unison da vida - se algum disco seu tiver uma velocidade de I/O ruim, provavelmente vai afetar bastante o desempenho...
Quanto as grandes diferenças de velocidade de transmissão, não sei pq isso acontece, mas já tive esses problemas - e nao sei como resolver. No caso da linha de comando, é fácil resolver... basta logar na máquina certa. O fato é que o ssh é um protocolo pesado, que usa bastante CPU - e nao sei se é simetrico em termos de CPU (ambos os hosts, gastam o mesmo tanto?) 

[1] http://kerneltrap.org/node/5070


--
Marcos
Reply to: