[Rio-pm] Metodos de Download em Massa

Qui Maio 25 06:12:04 PDT 2017

Gostei desse Future. Talvez possa usar como alternativa para IPC::ShareTables em algumas situações.

Quanto ao Fork, eu passei muito tempo na sombra quanto ao assunto de threads, forks, parallel, async, queue, ..., vejo muitas pessoas com posições diferentes mas a maioria fala pra evitar threads por exemplo, eu mesmo nunca usava nada por causa das diversas opnões (e infelizmente computação não é minha principal expertize), mas eu aprendi que tudo depende.

No caso do meu script, eu uso fork pra fazer varios downoads, é uma atividade simples na maioria das vezes, e no final se você acompanha os processos (pai e filhos), o consumo de memoria e CPU é praticamente 0 cada (juro, mem = 0, cpu <= 0.7), então o máximo que pesa nesse caso é o número de PIDs que o sistema vai gerenciar. Devo ta falando muita besteira, mas continuando, o problema que eu vejo em fork nesse caso é imprimir o download. Nesse caso é um problema de pós processamento, que pode ser resolvido linearmente, gerando temp files pra cada download depois unindo tudo seria uma solução. Minha pergunta nesses casos é: "quanto essa etapa influência no desempenho total do programa?".

Por exemplo, eu tenho uma aplicação que simplismente faz wraper que encapsula um outro programa de bioinfo, é um programa que mesmo você pedindo pra usar 8 cpu demora (dependendo do dataset) 20h pra terminar, eu não me importo em um servidor criar 40 maquinas virtuais com 8 cpu cada e paralelizar com fork mesmo todos os processos filhos e terminar tudo em 30 minutos mesmo que pese. Claro que depende de recursos computacionais tbm.

No final não é so custo, mas benefício tambem.

Especificamente no caso desse downloader não é necessidade, é mais o caso de criar opções e explorar possibilidades, pois tenho outros downloaders que resolvem meu problema, so que esse é o primeiro que devide e paraleliza os processos.

________________________________
From: Rio-pm <rio-pm-bounces+guedes_1000=hotmail.com em pm.org> on behalf of Renato Santos <renato.cron em gmail.com>
Sent: Wednesday, May 24, 2017 9:57:19 PM
To: Perl Mongers Rio de Janeiro
Subject: Re: [Rio-pm] Metodos de Download em Massa

Recomendo usar qualquer coisa menos forks para fazer downloads.

Forks são pesados, geram muitas trocas de contextos desnecessárias para tarefas tão triviais como downloads em paralelo.

Se o yada ta complicado, ainda tem o https://metacpan.org/pod/HTTP::Async que com o Future fica uma mão na roda

Algo como:

use Future;
use Future::Utils qw( try_repeat fmap1 );
use IO::Async::Loop;
use Net::Async::HTTP;

my $loop = IO::Async::Loop->new;
my $http = Net::Async::HTTP->new(  # serio, é assim q eu uso em produção, com max_connections_per_host=400
    max_connections_per_host => 400,
    timeout                  => 10 * 60
);
$loop->add($http);

sub DO_SOMETHING {
    my ( $algum_content, $url, $algum_contexto_talvez ) = @_;

    my $what = $http->do_request(
        method       => 'GET PORT DELETE...',
        uri          => "$url",
        content_type => 'text/plain',
        headers      => [
            'Content-Type' => 'text/plain'
        ],
        content => ( join "\n", @$algum_content )
    );

    $what = try_repeat { $what } until => sub {
        eval { $_[0]->get->code == 200 };
    };

    return $what;
}
my @futures;
for my $url ( 1 ... 100 ) {
    my $future =
      DO_SOMETHING( [...], $url, $algum_contexto_talvez )->on_done(
        sub {
            my $res = shift;

            if ( $res->content =~ /401 Unauthorized/ ) {

                # trata como se fosse erro, por exemplo
            }
            else {
                # ...
            }

        }

      )->on_fail(
        sub {
            my $failure = shift;
            log_error "error: $failure";
        }
      );

    push @futures, $future;
}

my @results = Future->needs_all(@futures)->get;

2017-05-24 16:53 GMT-03:00 Felipe Leprevost <leprevostfv em gmail.com<mailto:leprevostfv em gmail.com>>:
Apenas como curiosidade Aureliano, de onde você está tentando obter os arquivos ?

On Wed, May 24, 2017 at 3:21 PM Felipe da Veiga Leprevost <felipe em leprevost.com.br<mailto:felipe em leprevost.com.br>> wrote:
Apenas como curiosidade Aureliano, de onde você está tentando obter os arquivos ?

On Wed, May 24, 2017 at 3:19 PM Aureliano Guedes <guedes_1000 em hotmail.com<mailto:guedes_1000 em hotmail.com>> wrote:

Opa,

Yada achei muito complicado pra pouca coisa que vou fazer. Mas to convencido a tentar.

Breno, o truncado é por causa que estou fazendo varios downloads com o Parallel::ForkManager de um arquivo no formato texto, onde cada identificador é um dado do arquivo, como eu trabalho com milhoes desses identificadores e o servidor recomenda se limitar a 500 por requisição acaba que tenho que fazer varios downloads. So que to imprimindo tudo em STDOUT e redirecionando a saida pra um aarquivo estilo UNIX mesmo > , então tem varios processo tenetando escrever na tela ao mesmo tempo, eu pensei em fazer um lock mas acho q isso vai fazer demorar.

Exatamente aqui é o problema, IPC::ShareTable ou algo assim deve resolver. Alguma sujestão de solução ?

my $pm = new Parallel::ForkManager($req);
while(my $id = <$IN>){
$cnt++;
chomp $id;
if ($cnt == $split || $. == $nl){ #$split = 500;
push @ids, $id;
my @tmp = @ids;
undef @ids;
$cnt = 0;
$pm->start and next; # do the fork
my @resp = get_fasta(\@tmp, $db, $timeout);
if ($resp[0]){
$resp[1] =~ s/^\s*\n+//mg;
print STDOUT $resp[1];
}
else{
print STDERR "Status: $resp[2]\n$resp[3]\nDetails: $resp[1]\n";
print STDERR join (" ", "Fail:", @tmp, "\n");
}
$pm->finish; #tihs is a fork, at the end (here) the memory will be released
}
else{
push @ids, $id;
}
}
$pm->wait_all_children;

________________________________
From: Rio-pm <rio-pm-bounces+guedes_1000=hotmail.com em pm.org<mailto:hotmail.com em pm.org>> on behalf of breno <oainikusama em gmail.com<mailto:oainikusama em gmail.com>>
Sent: Wednesday, May 24, 2017 3:54:47 AM
To: Perl Mongers Rio de Janeiro
Subject: Re: [Rio-pm] Metodos de Download em Massa

Oi Aureliano,

se você está interessado em benchmarks, pode experimentar o LWP::Curl em vez do Furl, ou se tiver paciência pra ir direto ao metal, Net::Curl ou WWW::Curl.

O que quer dizer com "truncado"? Se a conexão cai depois de X bytes baixados (e se vc consegue garantir que o arquivo parcial contém apenas dados válidos), vc pode baixar só o que falta e depois juntar os dois pedaços na mão. Por exemplo, se o arquivo parcial foi baixado em "parcial.tmp":

---------8<---------
my $ua = Furl->new;
my $res = $ua->get( 'http://exemplo.com/arquivo.tmp', Range => 'byes=' . -s 'parcial.tmp' . '-');
open my $ fh, '>>', 'parcial.tmp;
print $fh, $res->content;
close $fh;
---------8<---------

(código não testado, estou no celular)

Se o servidor suporta conteúdo parcial (ele responde o primeiro request com Accept-Ranges), isso deve baixar o resto do arquivo. Idealmente, em vez de sobrescever o arquivo parcial, vc junta o conteúdo dos dois em um terceiro arquivo.

Finalmente, se quiser baixar vários pedaços do arquivo em paralelo, pode experimentar o HTTP::Range e o LWP::Parallel::UserAgent, ou se inspirar neles e implementar sua própria solução paralela com Furl ou LWP::Curl.

[]s
-b

On 23:26, Tue, 23 May 2017 Aureliano Guedes, <guedes_1000 em hotmail.com<mailto:guedes_1000 em hotmail.com>> wrote:

Ola Monges,

Gostaria de saber qual metodo vocês mais gostam para fazer downloads em massa.

Eu usava muito LWP, recentemente comecei usar uma combinação de Parallel::ForkManager e Furl, mas pra meu tipo de dado tem truncado parte dos download. (vale uma dica pra lidar com dados truncados?)

No meu caso, eu to fazendo download de mais me milhoes de sequencias, pra isso eu sigo a regra do servidor e peço apenas 500 por vez e limito em 10 fork.

Tem outros metodos que posso usar mas acabo perdendo e muito a eficiência. Por isso pretendo testar um benchmark em varias formas diferentes.

Bom, sei que existem ferramentas, BioPerl, etc...

Abraços,
acpguedes

_______________________________________________
Rio-pm mailing list
Rio-pm em pm.org<mailto:Rio-pm em pm.org>
http://mail.pm.org/mailman/listinfo/rio-pm
_______________________________________________
Rio-pm mailing list
Rio-pm em pm.org<mailto:Rio-pm em pm.org>
http://mail.pm.org/mailman/listinfo/rio-pm
--
Felipe da Veiga Leprevost, Ph.D.
www.leprevost.com.br
Proteome Bioinformatics Lab
University of Michigan
--
Felipe da Veiga Leprevost, Ph.D.
www.leprevost.com.br
Proteome Bioinformatics Lab
University of Michigan

_______________________________________________
Rio-pm mailing list
Rio-pm em pm.org<mailto:Rio-pm em pm.org>
http://mail.pm.org/mailman/listinfo/rio-pm

--
YAGNI,
Renato CRON
http://www.renatocron.com/blog/
@renato_cron<http://twitter.com/#!/renato_cron>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20170525/77d1cc2a/attachment-0001.html>