Posts com a Tag ‘performance’
Um portal Joomla preparado para um bombardeio de acessos 3
sexta-feira, 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 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
O 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 é:
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
Tableless 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
Framework 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.
Um portal Joomla preparado para um bombardeio de acessos 2
sábado, 24 de outubro 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á!
Últimos posts comentados