Arquivo da Categoria ‘Desenvolvimento’

Como funciona o sistema de Cron do Magento

quarta-feira, 11 de agosto de 2010

O termo Cron vem da funcionalidade de agendamento de tarefas no Unix. No Magento o seu proposito é o mesmo. É importante deixar o Cron configurado pois ele é responsável por manter a loja funcionando de forma correta.

Periodicamente scripts do Magento precisam ser executados para executar tarefas como:

  • Reindexar preços de catálogo(melhora performance de busca)
  • Enviar newsletters
  • Gerar o Google Sitemap
  • Alertar usuários de mudanças de preço ou estoque
  • Atualizar automaticamente cotação de moedas estrangeiras
  • Fazer limpeza de logs no banco de dados
  • Executar periodicamente tarefas que você desenvolveu no seu módulo, etc.

Gastei um tempo para tentar entender como funciona exatamente o sistema de Cron, pois é bastante confuso. Em algumas documentações eu vi que deveria agendar o cron.php para rodar, em outras me diziam que isso deveria ser feito pela administração. Com um tempo de estudo entendi como funciona e vou explicar agora.

Agendamento de tarefas dos módulos

Cada módulo do Magento possui seu próprio agendamento. Nem todos os módulos vão rodar sempre no mesmo horário. Vamos tomar como exemplo o módulo de Newsletter.

Para que este módulo envie as newsletters programadas no dia e horário configurado pelo administrador é necessário que algum script seja executado em determinado período. Para fazer essa configuração o arquivo config.xml do módulo possúi a seguinte configuração:

<config>

    <!-- ... -->

    <crontab>
        <jobs>
            <newsletter_send_all>
                <schedule><cron_expr>*/5 * * * *</cron_expr></schedule>
                <run><model>newsletter/observer::scheduledSend</model></run>
            </newsletter_send_all>
        </jobs>
    </crontab>

    <!-- ... -->

</config>

A expressão */5 * * * * significa que o script deverá rodar todo dia a cada 5 minutos. A notação é a mesma utilizada no crontab do Linux. Já a reindexação de preços possui a expressão 0 2 * * * que significa que rodará todos os dias as 2:00 a.m.

Como o magento gerencia as tarefas

Para o Magento gerenciar essas tarefas ele possui uma tabela especifica chamada cron_schedule. Dentre as colunas da tabela há as que se destacam:

  • job_code: código do processo a ser executado
  • status: status da tarefa
  • scheduled_at: data e hora em que a tarefa está prevista para ser executada

Tomando ainda de exemplo o módulo de Newsletter, teremos na tabela cron_schedule os valores:

Essa linha informa que o processo newsletter_send_all, ou seja os envios de Newsletters será executado às 14:35 do dia 06/08/2010. Uma vez executado o status muda para "success". De acordo com que o arquivo cron.php for rodando ele criará mais registros como esse agendando a tarefa para 14:40, 14:45, 14:50, etc.

Na raíz do Magento há um arquivo chamado cron.php. Este arquivo é responsável por gerenciar toda a parte de agendamento. Ele criar os agendamentos na cron_schedule, roda as tarefas em seus devidos horários, limpa tarefas antigas, etc. Ele deve ser executado periodicamente para fazer a gerência de tarefas. Você pode configurá-lo dentro do seu servidor utilizando o Crontab(Linux) ou o Agendador de Tarefas(Windows). Se você não puder fazer essa configuração no seu servidor ou seu serviço de hospedagem não da suporte você pode optar por usar serviços on-line como o http://cronless.com/ ou o http://www.onlinecronjobs.com/.

Eu recomendo que este arquivo seja chamado a cada 5 minutos. Assim fica mais difícil tarefas serem executados fora do horário previsto ou até mesmo causar uma sobrecarga de tarefas sendo executadas, por exemplo, seu arquivo foi executado na ultima vez às 14h e você configurou para ele ser chamado a cada 30 minutos, logo a próxima vez que ele rodar será às 14:30. Todos os processos que foram agendados para rodar entre 14 e 14:30 vão ser executados todos de uma vez às 14:30.

Configurações de execução de cron no Magento

O Magento possúi algumas configurações relacionadas aos agendamentos de tarefa. Se você for em Admin > System > Configuration > System > Cron(na versão inglẽs) verá as seguintes opções:

  • Generate schedules every
    Tempo(em minutos) em que será gerado na tabela cron_schedule um registro com agendamento de tarega. Exemplo: Se esta opção está setada com o valor 15 e o cron.php rodou pela última vez às 14h então só será gerado registros de agendamento às 14:15. Se o cron.php rodar às 14:10 nada fará além de executar tarefas agendadas naquele horário. Valor recomendado: 60.
  • Schedule ahead for
    Será gerada tarefas até x minutos a frente. Exemplo: se este valor está setado para 10, o cron.php roda às 14h e a tarefa deve ser rodado de 5 em 5 minutos, será gerado na tabela cron_schedule tarefas para às 14:00, 14:05 e 14:10. Valor recomendado: 15.
  • Missed if not run within
    Tempo em minutos em que uma tarefa será considerada perdida. Exemplo: Se estiver configurado com o valor 3, a tarefa está programada para rodar às 14h o arquivo cron.php deve rodar até as 14:03 ou então esta tarefa não rodará mais e seu status mudará para "missed". Valor recomendado: 60.
  • History cleanup every
    Tarefas executadas ou perdidas serão limpas a cada x minutos. Valor recomendado: 120.
  • Success history lifetime
    Registros de tarefas executadas com sucesso ficará por até x minutos após sua execução. Valor recomendado: 120.
  • Failure history lifetime
    Registros de tarefas executadas e falharam ficará por até x minutos após sua execução. Valor recomendado: 120.
Tags / - -
Bruno Viana / 11 de agosto de 2010

Unicode e o fim dos problemas de codificação

sexta-feira, 28 de maio de 2010

Problemas com codificação sempre foram recorrentes no desenvolvimento de softwares, mas isso vem se tornando cada vez mais presente devido à globalização. O mundo é menor do que se imagina, e pessoas do outro lado do globo estão observando seu site ou usando seu sistema. Como alguém da China vai entrar em contato com você para apresentar uma proposta bilionária se tudo que ela enxerga no seu site são apenas “?? ??? ???” ? Entenda por que isso acontece e fuja das gambiarras na hora que seu cliente estiver no telefone lhe pedindo uma solução para ontem.

(mais…)

Bruno Viana / 28 de maio de 2010

Crescimento do Comércio Virtual no Brasil

terça-feira, 4 de maio de 2010

Pesquisas revelam que é cada vez maior o número de usuários da grande rede virtual que optam por fazer compras pela internet em vez de sair de casa e se dirigir até alguma loja. A praticidade e a comodidade tornam as buscas muito mais fáceis e todo produto comprado é recebido após alguns dias pelo correio.

Por causa disso, empresas de diversos setores estão se atualizando e criando seus portais para comércio virtual, oferecendo também on-line, tudo que normalmente é oferecido nas suas lojas.
O cliente em vez de pegar um engarrafamento, um dia de muito calor ou um dia de chuva, pode, na própria casa, escola ou trabalho, evitar possíveis transtornos e efetuar suas compras de qualquer lugar.

O início foi meio tímido, eram vendidos apenas livros, CDs, produtos eletrônicos, mas agora serviços também são vendidos na internet, como pacotes turísticos, por exemplo.

Os dados mostram que essa nova tendência de comercialização vem trazendo um crescimento considerável para a economia brasileira. O aumento de clientes on-line cresce principalmente pelo aumento de internautas e porque os produtos nas lojas convencionais esgotam o estoque, ocasionando menos opções, enquanto as lojas web oferecem uma variedade maior de produtos.

A e-bit, empresa especializada em informações de comércio virtual, destaca o aumento da participação de varejistas de pequeno e médio porte nos tramites on-line. Comparando com o primeiro trimestre de 2009, eles ganharam 37,26 milhões reais a mais em relação ao mesmo período em 2008. Em 2010 isso deve aumentar.
“O comercio eletrônico, de uma forma geral, tem evoluído em termos de serviço prestado ao consumidor”, diz Pedro Guasti, diretor-geral da e-bit. “Como a barreira de entrada é menor, há um volume grande de investimentos mais baixos, mas que não abrem mão da qualidade”.

Forrester Research, afirma que as vendas on-line de produtos atingiram R$2,8 bilhões em 2005 e em 2010 deverão chegar a R$12,8 bilhões, representando uma taxa de crescimento anual de 38%.

Aos poucos, os brasileiros estarão ainda mais inseridos aos meios virtuais e ao comércio eletrônico, é só uma questão de tempo.
 

Fonte: InfoAbril e B2winc
 

Danilo Castro / 4 de maio de 2010


No primeiro post Um portal Joomla preparado para um bombardeio de acessos. Vemos que é necessário fazer na garagem, chegou a vez do tanque de combustível

 

No Segundo post falamos sobre as bases de dados que seria o tanque de combustível.

 

Agora chegou a vez do Motor e da Lataria

Continuando a nossa busca pela máquina perfeita, vamos agora falar sobre os elementos que podem ser “fuçados” no motor e quais seriam os elementos de design para aumentar a potência e a estabilidade do nosso portal desenvolvido em Joomla.

Falando de motor

motorO Joomla tem alguns elementos nativos da ferramenta, alguns que ajudam e outros que podem atrapalhar. Com um ajuste fino é possível deixar redondo e obter a melhor performance.

Cachê – Estas funcionalidades ficam no backend do joomla na opção site >> Configuração Global opção sistema. O objetivo da função cachê é diminuir as requisições à base de dados e assim acelerar o acesso, guardando as respostas aos pedidos à base de dados durante um determinado tempo (que o próprio administrador decide). Não entendeu?

Cachê ativado - significa que a resposta ao pedido do browser é dada a partir de um pedido anterior evitando-se novo pedido à base de dados.
Cachê desativada – significa que cada usuário que entrar no site vai consultar o banco de dados para montar a página.

A duração do cachê é uma opção configurável e em geral o melhor que eu indico é:     

Recomendações de cache.

Session – A configuração desta funcionalidade diz quanto tempo vai durar a seção de acesso criada para cada usuário que visita o site. Neste caso a melhor configuração seria algo em torno de 20 a 80 minutos para que a seção não finalize rapidamente e seja necessário novo processamento para criar uma nova sessão.

Estatística de acesso a banners - O joomla contabiliza todos os acessos e views (visualizações) dos banners o que prejudica e muito a performance. Em websites com milhões de acessos, não tem jeito, temos que perder esta funcionalidade. Imagine um portal com 10 banners na home e 100 acessos simultâneos? Teríamos 1000 updates simultâneos para o MySql executar.
Como corrigir o problema?

Cometendo o pecado de alterar o código do CORE. (Infelizmente)
components/com_banners/banners.php linha 108 a 116

$query = 'UPDATE #__banner'
            ' SET impmade = impmade + 1'
            ($expire ? ', showBanner=0' : '')
          ' WHERE bid = '.(int) $item->bid;

$db->setQuery( $query );
            if(!$db->query()) {
              JError::raiseError( 500, $db->stderror());
         }

Query de busca – O select executado pelo joomla no componente de busca está longe de ser considerado um primor, quando se trata de muitos acessos é claro que isso faz toda a diferença. Além de customizar e melhorar a query de busca uma saída indicada é substituir o select simples que o joomla faz por FULL TEXT. Mas afinal o que seria isso? Trata-se de trocar a consulta comum que é executada pelo JOOMLA e utilizar essa técnica do mysql: MATCH (col1,col2,…) AGAINST (expr [search_modifier])
 (http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html).
Detalhe, esta técnica só funciona com tabelas do tipo MyIsam.

Ordering no com_content - O componente com_content faz parte da vida de quem trabalha com o joomla, é ele o responsável pelo cadastramento de conteúdos do site. Existe um problema no administrator que acontece quando; Cadastramos um novo conteúdo, desabilitamos ou o selecionamos para a FrontPage(home). Ao sofrer algumas destas ações o com_content reordena todos os conteúdos, ou seja, desencadeia uma quantidade enorme de up-dates em registros da tabela jos_content. A melhor opção e desabilitar esta funcionalidade automática e somente o fazer quando o usuário der o comando nos gerenciamentos de ordenação disponíveis
 

Uso indiscriminado de extensões - É impossível dizer com exatidão quantas extensões existem para joomla disponíveis na web. Às vezes a facilidade que algumas delas oferecem para resolver o nosso problema pode se tornar uma dor de cabeça em questões de segurança e performance, a saída não existe. Porém o melhor a se fazer é baixar somente as que estão no joomla.org que hoje são em torno de 3.579. Sempre que optar por usar uma extensão esteja ciente de que ela não é parte do joomla e por isso não é de responsabilidade do core.

Falando de Lataria

É isso, vamos agora falar de design, assim como nos carros o desenho do carro ajuda na estabilidade e na performance.
Abaixo segue um quadro que demonstra as Leis de construção de layouts turbinados

Logomarca do tablelessTableless X tabelas – Use tableless. O código fica menor, quantidade de kbytes da página cai, além de proporcionar uma execução mais uniforme e inteligente do código.

Reutilização de classes CSS – Sempre opte pela construção de código CSS que se utilize de herança, pois isso também vai reduzir a quantidades de linhas e o tamanho dos arquivos. css

Utilização correta para extensões de imagens – Apesar de ser um assunto batido é sempre bom relembrar que PNG e GIF é para Ícones e imagens menores e JPG é para imagens com maior número de cores e mais riqueza de detalhes
    
javascriptFramework javascript – Escolha apenas 1, processar 2 ou mais framework pode afetar o desempenho, pois será necessário fazer esse duplo carregamento

Código CSS em uma linha só – O código CSS edentado é ótimo para programadores, é péssimo para o desempenho, em produção envie o código todo em uma linha só isso vai reduzir o tamanho do arquivo em 60% e representa um ganho mais que relevante de processamento.

Estas práticas vão ajudar e muito no desempenho do portal, finalizo aqui a série de três matérias de melhoria de desempenho em joomla. O conjunto destas ações vai fazer com que o seu portal tenha a força de um trator e a velocidade de um formula 1. O que é isso, um tratormula 1?
 
Daniel Leandro (twitter @danielleandro).
Agradecimento especial a Rafael Berlanda twitter(@berlanda) e Reinaldo Soares especialistas em performance e segurança joomla do ministério da educação que colaboraram mesmo sem saber com essas séries de artigos.

 

Daniel Leandro / 13 de novembro de 2009

No primeiro post Um portal Joomla preparado para um bombardeio de acessos. Vemos que é necessário fazer na garagem, chegou a fez do tanque de combustível
 

O Mysql

 

O Mysql é respeitado por alguns, questionado por outros. O importante é que o Mysql conquistou seu espaço e é hoje o olicerce do joomla,  wordpress e drupal. Preciso falar mais alguma coisa? E ainda, não é ele que está em questão aqui, mas sim uma maneira como é tratado o bloqueio de tabelas. Livre de deadlock.

 


Explicando o Problema tim tim por tim tim.

O MySQL utiliza bloqueio de tabelas (no lugar de bloqueio de registros ou colunas) em todos os tipos de tabelas, exceto tabelas BDB, para obter uma alta velocidade nos bloqueios. Para grandes tabelas, bloqueio de tabelas é MUITO melhor que bloqueio de registros para a maioria das aplicações, mas existem, é claro, algumas desvantagens.

Para tabelas BDB e InnoDB, O MySQL só utiliza bloqueio de tabelas se você bloquear explicitamente a tabela com LOCK TABLES ou executar um comando quer irá modificar todos os registros na tabela, como ALTER TABLE. Para estes tipos de tabelas nós recomendamos a você não utilizar LOCK TABLES.

No MySQL versão 3.23.7 ou superior , você pode inserir registros em tabelas MyISAM ao mesmo tempo que outras threads estão lendo da mesma tabela. Perceba que atualmente isto funciona somente se não existirem buracos depois de registros apagados na tabela no momento que a inserção é feita. Quando todos os buracos forem preenchidos com novos dados, inserções concorrentes irão automaticamente ser habilitadas novamente.

O bloqueio de tabelas habilita várias threads para lerem de uma tabela ao mesmo tempo, mas se uma thread desejar escrever a uma tabela, ela primeiramente deve obter acesso exclusivo. Durante a atualização, todas outras threads que desejarem acessar esta tabela em particular irão esperar até que a atualização acabe.

Como atualizações em tabelas normalmente são consideradas mais importantes que SELECT, todas as instruções que atualizam uma tabela tem maior prioridade que instruções que simplesmente recuperam informações. Isto deve garantir que atualizações não fiquem na fila por terem sido passadas várias consultas pesadas em uma tabela específica. (Você pode alterar isto utilizando LOW_PRIORITY com a instrução que faz a atualização ou HIGH_PRIORITY com a instrução SELECT.)

A partir do MySQL versão 3.23.7 pode-se utilizadar a variável max_write_lock_count para forçar o MySQL a fornecer temporariamente a todas as instruções SELECT, que esperam por uma tabela, uma prioridade mais alta depois de um número específico de inserções em uma tabela.

O bloqueio de tabela não é, no entanto, muito bom sobre os seguintes cenários:

1 – Um cliente emite uma SELECT que exige muito tempo para ser executada.

2 – Outro cliente então executa um UPDATE na tabela usada. Este cliente terá que esperar até que a SELECT seja terminada.

3 – Outro cliente executa outra instrução SELECT na mesma tabela. Como UPDATE tem maior prioridade que SELECT, esta SELECT irá esperar pelo término da UPDATE. Ela também irá esperar pelo término da primeira SELECT!
Uma thread está esperando por algo do tipo disco cheio, caso em que todas as threads que desejam acessar a tabela com problema irão ser colocadas em estado de espera até que mais espaço em disco seja disponível.
 


Algumas soluções possíveis para este problema são:

1 – Tente deixar suas instruções SELECT sempre rápidas. Você pode ter que criar algumas tabelas de resumo para fazer isto.

2 – Inicie o mysqld com –low-priority-updates. Isto irá fornecer a todas instruções que atualizam (modificam) uma tabela prioridade menor     que uma instrução SELECT. Neste caso a última instrução SELECT no cenário anterior deveria executar antes da instrução INSERT.

3 – Você pode fornecer a uma instrução INSERT, UPDATE ou DELETE específica menor prioridade com o atributo LOW_PRIORITY.

4 – Inicie o mysqld com um valor baixo para max_write_lock_count para fornecer bloqueios de LEITURA depois de um certo número     de bloqueios de ESCRITA.


Você pode especificar que todas as atualizações de uma thread específica deve ser feita utilizando prioridade baixa com o comando. Exemplo:

 


SQL: SET SQL_LOW_PRIORITY_UPDATES=1.
Você pode especificar que uma     SELECT específica é muito importante com o atributo HIGH_PRIORITY.


“Sintaxe SELECT” – Se você tiver problemas com INSERT combinado com SELECT, utilize as novas tabelas MyISAM, pois elas suportam SELECTs e INSERTs concorrentes. Se você utiliza principalmente instruções INSERT e SELECT misturadas, o atributo DELAYED no INSERT provavelmente irá resolver seus problemas.


“Sintaxe INSERT” – Se você tiver problemas com SELECT e DELETE, a opção LIMIT para DELETE pode ajudar.

Sistema de injeção


Ao fazer a instalação default do joomla o banco é criado com tabelas do tipo MyIsam que são as consideradas mais rápidas quando o assunto é select que é o que mais se espera de demanda para um portal de conteúdos. Porém existem as particularidades do joomla como por exemplo o controle de sessão de usuários por banco de dados atrávéz da tabela jos_session e o update da view banner na jos_banners.O pulo do gato aqui é simples:

Tabelas que sofrem apenas SELECTS devem ser do tipo MyIsam


Tabelas que sofrem UPDATES, INSERTS E DELETES devem ser do tipo InnoDB
 
No próximo post falaremos sobre as otimizações de código fonte (O que fica debaixo do capô) e a questão do layout (Lanternagem e pintura) para finalizar a montagem desta máquina. Até lá!

Daniel Leandro / 24 de outubro de 2009