[SP-pm] downloader survey

[Stanislaw Pusep]

>
> Isso depende do processo externo e de como você está forkando. Se você
> deixar pra modificar absolutamente o mínimo de dados dentro do processo
> forkado, acho bem difícil que um processo completamente novo ocupe menos
> memória, já que você se beneficia do copy-on-write.
>

Código para testar lftp:
https://metacpan.org/source/SYP/AnyEvent-Net-Curl-Queued-0.009/eg/benchmark.pl#L63

Código para testar LWP::UserAgent:
https://metacpan.org/source/SYP/AnyEvent-Net-Curl-Queued-0.009/eg/benchmark.pl#L122

Resultado: lftp é 232% mais rápido, "desprezando o atrito".

   Stanislaw> E, para mim, como programador Perl, é deveras frustrante
>    Stanislaw> delegar os downloads ao lftp (http://lftp.yar.ru/
>    Stanislaw> )... Afinal, o que o lftp tem de tão bom que eu não possa
>    Stanislaw> fazer em Perl?! ;) Então, implementei o
>    Stanislaw> AnyEvent::Net::Curl::Queued, que é capaz de gerenciar
>    Stanislaw> filas bem grandes de downloads, de forma assíncrona. Mas
>    Stanislaw> será que compensa usá-lo ao invés do lftp? Para isso,
>    Stanislaw> comecei fazendo benchmarks.  Agradeço a todos pelas
>    Stanislaw> sugestões! Seguem as minhas observações:
>
>    Stanislaw>  1. Eden, você está certo, os "filhotes" do LWP tem uma
> inicialização muito lenta; e o mais curioso é que
>    Stanislaw>     boa parte da inicialização não está no new() propriamente
> dito, mas é feita durante o primeiro request
>    Stanislaw>     (). Então, para ser justo, dividi a minha fila de
> downloads em 10 filas separadas, e aloquei um fork()
>    Stanislaw>     para cada uma;
>
> Se você fizer um "warm-up" antes de forkar, talvez tenha mais benefício.
>

Fiz; continua "pesado".


>    Stanislaw>  4. wget tem o menor overhead de todas as alternativas por
> ser ridiculamente simples. Quase não tem
>    Stanislaw>     dependências, por isso a sua inicialização é quase
>    Stanislaw>     que instantânea;
>
> Mas ainda duvido que supere um processo com uma boa implementação
> forkante.
>

Supera LWP::Curl forkante, sendo 1151% mais rápido.


>    Stanislaw>  5. AnyEvent::HTTP é a melhor alternativa para acessar uma
> quantidade limitada de URLs *em paralelo*.
>    Stanislaw>     Porém, para listas razoavelmente grandes, gerenciamento
> via callbacks e closures é meio tenebroso...
>    Stanislaw>  6. Reiterando: o *MEU* interesse se restringe a pegar meio
> milhão de URLs e baixar de forma mais
>    Stanislaw>     eficiente possível (isso é, o gargalo deve ser minha
> bandwidth, não minha CPU/RAM). Nesse caso, pouco
>    Stanislaw>     me importa a possibilidade de fazer parsing de headers,
> gerenciar cookies ou processamento de HTML.
>    Stanislaw>     Isso é, quando eu quiser, devo poder habilitar tudo isso;
> mas o default deve ser OFF. Portanto, o meu
>    Stanislaw>     "Holy Grail" seria um libwget, que gerencia filas, extrai
> links e faz downloads recursivos :)
>
> Mas e se o download precisar de auth, sessão via cookie, proxy, ou
> qualquer uma das outras bizarrices do HTTP? Se você coletar casos de uso
> típicos, pode implementar um handler otimizado pra cada caso,
> introspectar os requisitos do download e fazer um lazy-loading da
> implementação correta, isso tudo antes de forkar.


libcurl FTW :)

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html
https://metacpan.org/module/AnyEvent::Net::Curl::Queued::Easy#setopt-OPTION-VALUE-OPTION-VALUE-

Não é tão obscenamente leve quanto wget, mas permite que as coisas simples
continuem simples, e as difíceis sejam possíveis ;)
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111024/46575a84/attachment.html>