eheheh... vários bons artigos nesse equinócio de Setembro. Valeu mongers!!!
LINK PARA O EQUINÓCIO
Esse é o meu artigo sobre XPATH. Espero que gostem!
Introdução ao XPATH e HTML::TreeBuilder::XPath
quinta-feira, 16 de setembro de 2010
terça-feira, 17 de agosto de 2010
Bye Bye forks Hello threads!!!
A algum tempo( desde perl 5.8 ), eu venho usando o módulo forks para trabalhos que envolvem multiprocessamento (ou processamento concorrente, se preferir ). O fato é que eu estava tendo muitos problemas com o forks, embora sempre tenha me dado muito bem com ele.
Só lembrando, forks é um módulo que 'sobrecarrega' o módulo threads, mas utiliza 'fork' para gerar os processos 'child' e 'parent'. Existe uma série de vantagens de usar forks ao invés de simplesmente o fork. Uma delas é a possibilidade de gerar um processo novo somente com o trecho do código que você precisa( embora outro processo seja gerado normalmente pelo S.O. ), de forma análoga as threads, além de poder compartilhar variáveis entre as 'pseudo threads' e outras coisinhas.
No entanto algumas situações me forçaram a abandonar o forks de vez. Primeiro, o sistema em que eu estava aplicando o forks não me permitia trabalhar com um daemon. Quando eu tentava executar uma tarefa, por exemplo, o módulo me gerava uma 'montanha' de mensagens de erro que envolvia inclusive permissão para sockets e outras bizarrisses.
Além do mais comecei a perceber que sem motivo aparente as 'pseudo threads' estavam parando, ou congelando. Mesmo usando eval, não consegui encontrar o problema, e foi a 'gota'!
Eu até tentei debugar isso diretamente no módulo, mas isso estava me consumindo tempo demais, já que não sou propriamente um 'guru' Perl( mas eu chego lá um dia... ), e acabei optando por testar o sistema com threads novamente.
Comecei primeiramente na minha estação, instalando a nova versão do Perl 5.12, com o thread-mode habilitado. Depois simplesmente troquei 'use forks' por 'use threads' no módulo onde eu faço o gerenciamento das antigas 'pseudo threads', levando em conta que forks tem todos os métodos que threads, como mencionei mais acima. Portanto não faria a menor diferença, certo??? Erradíssimo!! Fez TODA a diferença!!!
Diferentemente dos meus antigos testes com threads nas versões 5.8.x, tive um desempenho bem melhor, consumindo menos recurso do que usando forks. Fiz os testes executando os mesmos spiders( o sistema que eu mencionei gerencia atividades com spiders ), e medi os tempos com Datetime e Date::Calc e o consumo de memória com o comando top. Um teste superficial, admito. Mas as threads não cairam mais, e o tempo de execução diminuiu uns 3% + ou menos.
Num próximo artigo vou fazer testes com o módulo Benchmark, não percam!!!
Só lembrando, forks é um módulo que 'sobrecarrega' o módulo threads, mas utiliza 'fork' para gerar os processos 'child' e 'parent'. Existe uma série de vantagens de usar forks ao invés de simplesmente o fork. Uma delas é a possibilidade de gerar um processo novo somente com o trecho do código que você precisa( embora outro processo seja gerado normalmente pelo S.O. ), de forma análoga as threads, além de poder compartilhar variáveis entre as 'pseudo threads' e outras coisinhas.
No entanto algumas situações me forçaram a abandonar o forks de vez. Primeiro, o sistema em que eu estava aplicando o forks não me permitia trabalhar com um daemon. Quando eu tentava executar uma tarefa, por exemplo, o módulo me gerava uma 'montanha' de mensagens de erro que envolvia inclusive permissão para sockets e outras bizarrisses.
Além do mais comecei a perceber que sem motivo aparente as 'pseudo threads' estavam parando, ou congelando. Mesmo usando eval, não consegui encontrar o problema, e foi a 'gota'!
Eu até tentei debugar isso diretamente no módulo, mas isso estava me consumindo tempo demais, já que não sou propriamente um 'guru' Perl( mas eu chego lá um dia... ), e acabei optando por testar o sistema com threads novamente.
Comecei primeiramente na minha estação, instalando a nova versão do Perl 5.12, com o thread-mode habilitado. Depois simplesmente troquei 'use forks' por 'use threads' no módulo onde eu faço o gerenciamento das antigas 'pseudo threads', levando em conta que forks tem todos os métodos que threads, como mencionei mais acima. Portanto não faria a menor diferença, certo??? Erradíssimo!! Fez TODA a diferença!!!
Diferentemente dos meus antigos testes com threads nas versões 5.8.x, tive um desempenho bem melhor, consumindo menos recurso do que usando forks. Fiz os testes executando os mesmos spiders( o sistema que eu mencionei gerencia atividades com spiders ), e medi os tempos com Datetime e Date::Calc e o consumo de memória com o comando top. Um teste superficial, admito. Mas as threads não cairam mais, e o tempo de execução diminuiu uns 3% + ou menos.
Num próximo artigo vou fazer testes com o módulo Benchmark, não percam!!!
domingo, 18 de julho de 2010
quinta-feira, 15 de julho de 2010
WWW::Mechanize - problemas com 'memory leak'
Estava no trabalho tentando resolver um problema a quase três dias. Tratava-se de um spider que estava consumindo até 8GB de memória do servidor. O engraçado é que ele não fazia isso antes, mas enfim... O fato é que ele passou a se comportar assim.
Normalmente os parsers são culpados por problemas de 'memory leak' ( ou vazamento de memória ). Então concentrei meus esforços para descobrir em que ponto do spider estava gerando o leak, mas a única coisa que consegui foi 'atrasar' o problema. O parser que eu estava usando é o HTML::TreeBuilder::XPath, e eu já tive problema de 'memory leak' com ele. Logo parecia ser um bom 'alvo'.
Finalmente depois de quase três dias, eu resolvi descartar o parser e procurar outros culpados, foi quando me caiu a ficha... O agente poderia ser o culpado. Claro! Agora fazia sentido, mesmo porque lembrando dos monitoramentos das iterações, normalmente mem. subia quando alguma requisição era feita... :P .
O módulo que eu usei para ser o agente no caso foi o maravilhoso WWW::Mechanize. Então comecei a procurar referências no google e logo descobri várias pessoas tendo o mesmo problema. A solução, felizmente, é bem simples. Apenas re-instancie o módulo dentro das iterações e pronto!!! Problema resolvido!
Mas o que me deixou fulo foi o tempo que levei para descobrir. Muito tempo mesmo! Isso me deixou tão chateado, que resolvi que vou encontrar uma maneira de observar o problema mais eficientemente, e quando conseguir, vou escrever um módulo e um artigo.
Cheers!
Normalmente os parsers são culpados por problemas de 'memory leak' ( ou vazamento de memória ). Então concentrei meus esforços para descobrir em que ponto do spider estava gerando o leak, mas a única coisa que consegui foi 'atrasar' o problema. O parser que eu estava usando é o HTML::TreeBuilder::XPath, e eu já tive problema de 'memory leak' com ele. Logo parecia ser um bom 'alvo'.
Finalmente depois de quase três dias, eu resolvi descartar o parser e procurar outros culpados, foi quando me caiu a ficha... O agente poderia ser o culpado. Claro! Agora fazia sentido, mesmo porque lembrando dos monitoramentos das iterações, normalmente mem. subia quando alguma requisição era feita... :P .
O módulo que eu usei para ser o agente no caso foi o maravilhoso WWW::Mechanize. Então comecei a procurar referências no google e logo descobri várias pessoas tendo o mesmo problema. A solução, felizmente, é bem simples. Apenas re-instancie o módulo dentro das iterações e pronto!!! Problema resolvido!
Mas o que me deixou fulo foi o tempo que levei para descobrir. Muito tempo mesmo! Isso me deixou tão chateado, que resolvi que vou encontrar uma maneira de observar o problema mais eficientemente, e quando conseguir, vou escrever um módulo e um artigo.
Cheers!
domingo, 11 de julho de 2010
São Paulo Perl Mongers Workshop
Muito loko! O evento foi no dia 10/07, com a palestra inicial do Thiago Rondom, que introduziu HTTP para o pessoal, depois foi a vez do Tomas Doran. Cara bem excêntrico, mas fez ótimas palestras. Uma sobre boas práticas em projetos de desenvolvimento, ao invés de preocupações menores como 'qual webframework usar'.
Deu boas dicas sobre o que focar nos projetos e como analisar algumas situações corriqueiras e contornar problemas comuns a todos os projetos, e falou um pouco sobre o Catalyst também.
O Eden deu uma palestra sobre Catalyst + Reaction e tentou focar um pouco em como isso pode agilizar o processo de desenvolvimento utilizando Moose + alguns 'kitutes' como MooseX e Reaction, para atualizar widgets e comportamentos somente modificando a 'configuração' da classe responsável por aquele widget.
Tomas voltou com outras duas palestras, uma sobre Monitoramento, mas não me convenceu muito sobre a parte 'tempo real' na web, mesmo assim foi uma boa apresentação.
Por último Tomas falou sobre arquitetura de grandes plataformas em Perl, apresentando o seu dia-dia na empresa em que ele trabalha e como lidou com os vários problemas nos projetos.
No final, pra variar, fomos todos encher a cara no Don Mariano, onde pude conhecer um pouco melhor a figurinha. O pessoal o apelidou de 'WoodPeaker'(pica-pau), por causa do cabelo vermelho, mas ele levou na brincadeira. Cara bem-humorado e beberrão... pena que não curte rock'n roll... ehehe mas ninguém é perfeito!
O evento foi ótimo, muitas pessoas de fora apareceram e essecialmente, tudo deu certo! Só acho que ainda falta focar um pouco nas empresas, mas isso é algo que deve se ajustar com os outros eventos.
Deu boas dicas sobre o que focar nos projetos e como analisar algumas situações corriqueiras e contornar problemas comuns a todos os projetos, e falou um pouco sobre o Catalyst também.
O Eden deu uma palestra sobre Catalyst + Reaction e tentou focar um pouco em como isso pode agilizar o processo de desenvolvimento utilizando Moose + alguns 'kitutes' como MooseX e Reaction, para atualizar widgets e comportamentos somente modificando a 'configuração' da classe responsável por aquele widget.
Tomas voltou com outras duas palestras, uma sobre Monitoramento, mas não me convenceu muito sobre a parte 'tempo real' na web, mesmo assim foi uma boa apresentação.
Por último Tomas falou sobre arquitetura de grandes plataformas em Perl, apresentando o seu dia-dia na empresa em que ele trabalha e como lidou com os vários problemas nos projetos.
No final, pra variar, fomos todos encher a cara no Don Mariano, onde pude conhecer um pouco melhor a figurinha. O pessoal o apelidou de 'WoodPeaker'(pica-pau), por causa do cabelo vermelho, mas ele levou na brincadeira. Cara bem-humorado e beberrão... pena que não curte rock'n roll... ehehe mas ninguém é perfeito!
O evento foi ótimo, muitas pessoas de fora apareceram e essecialmente, tudo deu certo! Só acho que ainda falta focar um pouco nas empresas, mas isso é algo que deve se ajustar com os outros eventos.
terça-feira, 18 de maio de 2010
Assinar:
Postagens (Atom)