[SP-pm] downloader survey

[Thiago Rondon]

On Thu, Oct 20, 2011 at 05:25:20PM -0200, Stanislaw Pusep wrote:
>    OK, aqui vai o spoiler: estou fazendo benchmark (de overhead) de todos os
>    HTTP agents que conheAS:o. E oA LWP estA! *MUITO* feio na fita:
>    https://metacpan.org/module/AnyEvent::Net::Curl::Queued#OVERHEAD
>    ABS()

Stan,

Eu vou apontar para outro lado, já que me parece que teu objetivo é
perfomance para efetuar download de arquivos via http (tcp), e você
já esta testando as alternativas que há como módulo para realizar
tua tarefa. :)

Me parece que teu caso é:

- Uso do protocolo HTTP para baixar arquivos ;
- Encontrar o melhor algoritimo para trabalhar em paralelo no seu
  aplicativo;
- Verificar se você tem "banda" necessária para este trabalho.

Primeiramente, é interessante saber, quanto de banda você tem 
disponível ? Qual o tamanho dos arquivos que você vai efetuar download ? 
Ou seja, qual sua capacidade para buscar os arquivos, e qual 
'concorrencia' ?

Como é um caso para conectividade em paralelo, é interessante levantar 
alguns pontos da tua rede e do teu sistema operacional para saber se ele
suporta e esta preparado para esta demanda. Isto pode afetar o comportamento 
de alguns módulos.

Apesar do kernel 2.6 já ter muita coisa para o "autotuning" na pilha
TCP, é interessante olhar para alguns parametros, tais como:

- net/core/[r,w]mem_max e net/ipv4/tcp_[r,w]mem pode ser muito interessante em
  casos onde há conexões em paralelo, com excesso uso de conexões e 
  dados.

- net/ipv4/tcp_available_congestion_control - Este é um assunto que vale 
  ler, dependendo do local, da 'qualidade do link' você pode optar por
  um algoritimo, se tiver banda em excesso e etc, pode ser outra. Há 
  muita atualização destes algoritimos ao longo do desenvolvimento do 
  kernel 2.6, vale verificar e atualizar o kernel se você for alterar
  este parametro.

- txqueuelen é um bom parametro também para ser trabalhado, pois pode te
  oferecer uma boa perfomance neste cenário também, este parametro é 
  efetuado no device, por exemplo 'ifconfig eth0 txqueuelen 100000'

Em relação ao algoritimo de concorrencia, dependendo da quantidade que 
você quer, e se você esta de olho em perfomance, é interessante olhar
para o epoll no Linux. Eu ainda não usei os módulos que trabalham 
diretamente com ele, como o IO::Epool, mas há muita coisa surgindo
baseado nesta caracteristica "nova" que esta disponível no kernel, 
tais como nginx e etc. Fica uma pergunta.. Será que isto vai fazer 
realmente diferença ? Eu não sei, mas gostaria de ver seus resultados 
aqui. :)

Agora, o HTTP você pode utilizar o keep alive, dependendo também das
suas requisições, são para o mesmo host ? Se você tiver uma lista, é
uma boa ordenar por host, e dividir elas entre os processos que você
vai separar, ou seja, se você tiver 30 arquivos no host X, e 30 no
arquivo Y, organize eles para se aproveitar do keep alive, ou se for
tudo diferente desative ele.

Se os arquivos não foram compactados, e dependendo do tipo, e se 
banda for um 'problema', talvez vale apena ativar a compactação para
buscar os arquivos, onde os servidores suportarem.

Se a lista for 'grande' e 'diversificada', use o dns cache, e vá 
resolvando os nomes antes, para economizar uma etapa na hora que 
for para 'buscar'. 

Tome cuidado com roteadores bizarros que 'zoem' o MTU, isto pode
afetar bastante, um MTU alto pode te ajudar com transferir pacotes
com dados grandes.

Enfim, foram ideias que tive agora sobre o problema. :)

Acredito que o restante da discussão, é o que você já tá procurando,
que é como os módulos trabalham, e efetuam a tarefa que você quer, 
mas poste os resultados aqui, pois também estou curioso. :-)

Ps.: Lembre-se que todos os valores no /proc são volateis, então use o sysctl
para manter ele persistente no teu sistema. :)

Abs!
-Thiago Rondon