[SP-pm] requisições extremamente longas

Andre Carneiro andregarciacarneiro at gmail.com
Fri Mar 22 11:38:13 PDT 2013


Galera!

Vocês não vão acreditar!

Descobri o problema das requisições. Olhando via plugin 'Live Http Headers'
do Firefox, um camarada aqui do trampo desvendou o mistério. Acontece que
as requisições são redirecionadas através de um monte de javascript que
traz os dados aos poucos. Isso mesmo! Um get, vira vários gets passando um
contador. Esse contador é passado para a app Ruby que controla um limit no
banco de dados. PUTAKIPARIU, QUE VONTADE DE ARRANCAR A CABEÇA DO DESGRAÇADO
QUE CHEGOU NESSA SOLUÇÃO!!!

Desculpem o desabafo!


Enfim, ainda bem que foi resolvido!

Obrigado a todos pela força!!


Cheers!

2013/3/22 Andre Carneiro <andregarciacarneiro at gmail.com>

> Mantovani, nao tem erro! Por incrível que pareça, todos os arquivos são
> gerados, mas esses cujas requisições demoram mais, vem com menos dados(bem
> menos), e sim, rola timeout...
>
> O sistema faz logs das queries, e além disso, consegui que o pessoal que
> fez o treco em Ruby me enviasse as regras de ordenação que eles utilizaram.
> O resultado foi que, para vários relatórios,  funcionou! Mas entre mais de
> 100 relatórios gerados, 14 não funcionaram com a ordem que deveria. O
> motivo eu nem imagino, e a pressão para entregar essa joça é muito grande!
>
>
>
> Eden, não sei ainda se o problema está no client, mas vou tentar o
> AnyEvent, de qq forma, valeu! Quanto ao POE só em último caso...muito chato!
>
> Tiago, modificar o front-end não é uma opção no momento.
>
>
> Tentarei monitorar as requisições para ver se não estou 'defecando'
> exatamente nas requisições, deixando algo para trás. Talvez esteja faltando
> alguma coisa, sei lá... Quando tiver novidades, eu posto de novo. Enquanto
> isso, se alguém tiver mais alguma idéia, não deixe de compartilhar!
>
>
> Valeu, pessoal!
>
>
> 2013/3/21 Tiago Peczenyj <tiago.peczenyj at gmail.com>
>
>> 2013/3/21 Daniel de Oliveira Mantovani <
>> daniel.oliveira.mantovani at gmail.com>
>>
>>> Tiago Peczenyj, você está presumindo que a base de dados não tem
>>> standardization e o autor do código resolveu o problema usando código
>>> ?
>>>
>>
>> Sim. Standardization em rails significa rezar pra entender o que o cara
>> fez no ActiveRecord. Ainda mais se vc tiver queries polimorficas.
>>
>>
>>>
>>> 2013/3/21 Tiago Peczenyj <tiago.peczenyj at gmail.com>:
>>> >
>>> >
>>> > 2013/3/21 Renato Santos <renato.cron at gmail.com>
>>> >>
>>> >> Hauah ok, tem uma chance de funcionar
>>> >>
>>> >> O problema é que a lógica obscura do order by deve estar num código de
>>> >> ruby
>>> >
>>> > Não necessariamente.
>>> >
>>> > A logica obscura pode estar em algumas conversões de dados ou mesmo
>>> algumas
>>> > regras de negócio implicitas agrupando alguma coisa OU "if a == 7 then
>>> a =
>>> > 1987"
>>> >
>>> >>
>>> >> Em 21/03/2013 21:36, "Daniel de Oliveira Mantovani"
>>> >> <daniel.oliveira.mantovani at gmail.com> escreveu:
>>> >>
>>> >>> André, para tudo. Liga os logs do banco e pegue as queries ;)
>>> >>>
>>> >>> 2013/3/21 Andre Carneiro <andregarciacarneiro at gmail.com>:
>>> >>> > Salve!
>>> >>> >
>>> >>> > Estou com problemas para processar requisições extremamente
>>> longas. A
>>> >>> > situação é a seguinte:
>>> >>> >
>>> >>> > - Tenho um servidor Apache rodando Ruby on Rails, que por sua vez,
>>> roda
>>> >>> > um
>>> >>> > front-end de um sistema de pesquisas(survey).
>>> >>> > - Tenho um script Perl que precisa acessar as páginas desse
>>> front-end e
>>> >>> > recuperar alguns relatórios. Aí vocês me perguntam 'Por que você
>>> não
>>> >>> > acessa
>>> >>> > via Banco de dados? Bom, basicamente não consigo descobrir alguns
>>> >>> > detalhes
>>> >>> > sobre como o sistema ordena alguns dados, o que me gera vários
>>> >>> > problemas com
>>> >>> > os relatórios que eu preciso entregar, aí achei que o melhor
>>> caminho
>>> >>> > seria
>>> >>> > usar o relatório que já existe no front-end e filtrar apenas o
>>> >>> > necessário,
>>> >>> > sem alterar a ordem de nada.
>>> >>> > - O problema é que alguns relatórios são muito grandes, o que não
>>> >>> > impede o
>>> >>> > front-end gerar o arquivo e disponibilizar o link. Isso, a
>>> princípio, é
>>> >>> > feito on-demand, ou seja, tem um botão onde se clica para disparar
>>> uma
>>> >>> > requisição que faz com que essa app Ruby gere esses relatórios. E a
>>> >>> > requisição via browser não morre até o relatório ser gerado, não
>>> >>> > importando
>>> >>> > o tamanho desse relatório e/ou quanto demore. O grande problema é
>>> que
>>> >>> > eu não
>>> >>> > sei porque, quando eu faço essa requisição via Perl(WWW::Mechanize,
>>> >>> > LWP,
>>> >>> > WWW::Curl etc.) a requisição 'morre', e gera só um pedaço do
>>> arquivo.
>>> >>> >
>>> >>> > Algum código:
>>> >>> > <code>
>>> >>> >     my $m = WWW::Mechanize->new(autocheck => 1,
>>> >>> >                                 cookie_jar => HTTP::Cookies->new(
>>> file
>>> >>> > =>
>>> >>> > "$ENV{HOME}/.cookies.txt" ) ,
>>> >>> >                             );
>>> >>> >
>>> >>> >     $m->get('http://whatever.com');
>>> >>> >     if(!$m->succes){
>>> >>> >       #erro
>>> >>> >     }
>>> >>> >     else{
>>> >>> >       #ok, o arquivo foi gerado processe-o!
>>> >>> >
>>> >>> >     }
>>> >>> > </code>
>>> >>> >
>>> >>> > É isso! Alguma idéia?  Tá faltando informação?
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > Cheers!
>>> >>> >
>>> >>> > --
>>> >>> > André Garcia Carneiro
>>> >>> > Software Engineer
>>> >>> > (11)982907780
>>> >>> >
>>> >>> > =begin disclaimer
>>> >>> >    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>> >>> >  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>> >>> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> >>> > =end disclaimer
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> -dom
>>> >>>
>>> >>> --
>>> >>>
>>> >>> IBM - Business Analytics Optimization Consultant
>>> >>> Daniel Mantovani +5511 8538-9897
>>> >>> XOXO
>>> >>> =begin disclaimer
>>> >>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>> >>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>> >>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> >>> =end disclaimer
>>> >>
>>> >>
>>> >> =begin disclaimer
>>> >>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>> >>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>> >>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> >> =end disclaimer
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Tiago B. Peczenyj
>>> > Linux User #405772
>>> >
>>> > http://about.me/peczenyj
>>> > =begin disclaimer
>>> >    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>> >  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> > =end disclaimer
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> -dom
>>>
>>> --
>>>
>>> IBM - Business Analytics Optimization Consultant
>>> Daniel Mantovani +5511 8538-9897
>>> XOXO
>>> =begin disclaimer
>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>
>>
>>
>> --
>> Tiago B. Peczenyj
>> Linux User #405772
>>
>> http://about.me/peczenyj
>>
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
>
> --
> André Garcia Carneiro
> Software Engineer
> (11)982907780
>



-- 
André Garcia Carneiro
Software Engineer
(11)982907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130322/c351024c/attachment-0001.html>


More information about the SaoPaulo-pm mailing list