High Performance Websites – Melhorando sua performance

Todo administrador de redes que gerencia um site que possui alguns milhões de acessos por dia sofre de um grave problema: manter a performance com o alto volume de acessos.

A literatura a respeito disso é pouca, e em português quase nula. As empresas brasileiras que possuem sites assim pouco agem no sentido de melhorarem a performance de seus websites. Em geral quase todas elas colocam uma pilha de servidores atrás de um balanceador de cargas. Mas existe algumas formas mais inteligentes de garantir uma ótima performance sem ser na força bruta. Algumas exigem algum investimento, outras apenas um pouco de tunning nos webservers e outras ainda são apenas boas práticas muitas vezes esquecidas principalmente, pela falta de conhecimento do protocolo HTTP e de suas possíveis otimizações.

Há algum tempo eu conheci um plugin do Firefox chamado Yslow, basicamente ele tira algumas métricas da página analisada e dá uma nota para cada um dos itens analisados. Essa ferramenta foi construída com base nas lições de performance que o Yahoo enfrentou ao longo do tempo. Seu autor – Steve Souders -, que hoje trabalha no Google lançou um livro pela editora O´Reilly chamado High Performance Web Sites, onde fala de cada uma das recomendações (as mesmas que o Yslow mede).

Nos próximos artigos vou falar um pouco de cada uma das recomendações feitas pela ferramenta e mostrar como configurá-las em seu webserver. Algumas das recomendações exigem modificações na aplicação, então algumas destas dicas são muito válidas para os desenvolvedores web também.

Para instalar o plugin primeiro você precisa instalar o Firebug, outro plugin que faz uma análise dos diversos elementos de uma página. Com esses dois plugins instalados você já pode começar a brincar com a ferramenta e ver seus resultados.

Os próximos artigos seguem abaixo:

1. High Performance Websites – Fazendo poucas requisições HTTP
2. High Performance Websites – Content Delivery Network
3. High Performance Websites – Cabeçalho Expires
4. High Performance Websites – Gzip
5. High Performance Websites – Componentes CSS
6. High Performance Websites – Javascript
7. High Performance Websites – Evite expressões CSS
8. High Performance Websites – Javascript´s e CSS externos
9. High Performance Websites – DNS
10. High Performance Websites – Miniminize os Javascripts
11. High Performance Websites – Evite redirecionamentos
12. High Performance Websites – Remova scripts duplicados
13. High Performance Websites – as Etags
14. High Performance Websites – Cacheando componentes AJAX

Entendendo o Bacula

Uma das grandes dores de cabeça de qualquer administrador de redes é o Backup (na verdade o restore destes backups). Já fiz backups criando scripts de gerenciamento de cópias (tar via SSH), e até algumas soluções robustas e escaláveis. E quando o backup não é bem planejado na hora que precisamos do restore começam os problemas.

Recentemente resolvi implementar o Bacula, me baseei em um tutorial do Viva o Linux: http://www.vivaolinux.com.br/artigo/Montando-um-completo-servidor-de-backup-usando-Bacula/ e um dos meus grandes problemas sempre foi entender o funcionamento de Jobs, Pools, Volumes e toda aquela nomenclatura que toda ferramenta de backup possui.

O Bacula não deve nada à soluções corporativas e que custam uns belos trocados, o único senão dessa ferramenta, é a falta de amigabilidade de sua interface (em relação à outras soluções), mas isso é algo que eu espero que você esteja acostumado a lidar.

Não vou me ater nesse texto à instalação ou configuração do Bacula, mas sim as nomenclaturas existentes. Algumas são bem óbvias como os Schedules e Jobs mas outras deixam um pouco de dúvida e geram algumas incertezas de como realmente funcionam.

Entendendo Jobs e Schedules

A principal instrução do backup é o Job. Um job consiste, principalmente, de:

• FileSet: lista dos arquivos e diretórios que serão backupeados;
• Client: a origem do backup. O servidor de onde o Bacula irá buscar os arquivos. O Client pode ser o próprio servidor do Bacula, mas um bom exemplo é todos os servidores do seu datacenter;
• Schedule: é o agendamento, especifica quando o backup será realizado, desde o dia da semana até a hora em que o backup será realizado (algo semelhante ao cron). Também especifica qual o nível de backup que será feito: Full, Incremental etc;
• Pool: será explicado mais abaixo.

Claro que essas não são as únicas opções, mas são as essenciais.

Geralmente o par FileSet/Client combinam-se em um Job. A maioria das diretivas, como FileSets, Pools, Schedules, podem ser combinadas entre os Jobs, ou seja,  você poderá ter em 2 Jobs diferentes o backup de diferentes servidores (Client) usando o mesmo Schedule, o mesmo FileSet e talvez até o mesmo Pool. O Schedule irá definir que tipo de backup irá rodar e quando – por exemplo Full na Segunda e incremental no restante da semana. Quando mais de um Job usa o mesmo Schedule, a prioridade do Job determina quem irá rodar primeiro. Se você criar vários Jobs, pode usar a diretiva JobDefs para definir os parâmetros defaults para todos os Jobs. Isso pode ser alterado na configuração propriamente dita do Job, mas pode economizar um bom tempo e deixar a manutenção mais fácil.

Além dos Jobs para backup ainda existem Jobs para Restore, Verify (verificação) e admin jobs, que possuem requisitos diferentes.

Entendendo Pools, Volumes e Labels

Se você costuma usar programas como o tar para fazer seus backup, Pools, Volumes e Labels podem parecer bem confusos num primeiro momento. Um Volume é uma única fita física (ou um único arquivo) onde o Bacula irá gravar seus backups. Os Pools são grupos de Volumes.

Na configuração de  um Job você nunca irá especificar um Volume mas sim um Pool. Caso o backup definido no seu Job ocupe mais do que o espaço físico de um (1) Volume o Bacula irá pedir para que você monte o próximo Volume para que o backup possa terminar (se você utilizar arquivos como Volumes pode configurar para que estes sejam montados automaticamente, e o tamanho máximo de um arquivo, arquivos grandes demais podem ser uma dificuldade na hora do restore).

Apesar das opções do Pool serem definidas no Director, o Pool é mantido no catálogo do Bacula, que contém informações retiradas da configuração do Pool (bacula-dir.conf) bem como informações de todos os Volumes que foram adicionados ao Pool. Adicionar Volumes em um Pool normalmente é feito de forma manual, através do programa de Console do backup usando o comando Label.

Para cada Volume, o Bacula mantêm uma série de informações no catálogo, como por exemplo, a data/hora da primeira escrita, data/hora da última escrita, o número de arquivos do Volume, o número de bytes e o número de montagens, entre outras informações.

Antes que o Bacula leia ou escreva em um Volume, ele nomeia (Label) esse Volume, para que ao montá-lo tenha certeza de que está com o Volume correto. Isso é feito com o comando Label no programa de Console.

Os passos para criar um Pool, adicionar Volumes à ele, e escrever o Label nesses Volumes, podem parecer tediosos, mas são bem simples de executar e sua principal finalidade é que ao necessitar de um restore o Bacula irá requisitar o Volume(s) correto, agilizando o processo de restore. Você não precisará ficar abrindo fita por fita ou CD-R por CD-R no seu computador para saber onde está aquele arquivo que você acha que fez backup no ano passado, basta encontrá-lo no Bacula que ele praticamente faz todo o resto pra você.

Também com os Pools você pode criar suas próprias organizações. Você pode ter Pools “Diários” que gravam backups incrementais e Pools “Semanais” que só gravam backups Full. Como dito mais acima vários Jobs podem ter um mesmo Pool, assim no dia que você precisar de um restore, ou de algumas versões talvez sejam necessário 1 ou 2 fitas para fazer esse restore.

Fazendo a lição de casa

Ao configurar um sistema de Backup, seja ele qual for, tenha em mente que sua principal preocupação é o restore, e não o backup em si. Algumas preocupações que você deve ter são:

1. Defina uma política de backup, e tenha certeza que as pessoas na sua empresa conheçam essa política;
2. Ao definir sua política, monte um esquema sempre pensando no restore. Leve em conta as limitações de hardware (unidades de fitas LTO, CD-R) para definir o melhor esquema com o melhor custo benefício para sua empresa. Não tente fazer backup full de tudo, além de provavelmente não precisar, você irá gastar muito com fitas e o sistema de backup ficará caro demais. Lembre-se que embora você consiga justificar os custos do backup na sua empresa, seus superiores só entenderão o real valor dele quando precisarem (e se precisarem) do restore.
3. Arrume um tempo para, de tempos em tempos, rever sua estratégia de backup, talvez você encontre uma forma que gaste menos fitas do que você pensou originalmente.
4. Faça de vez em quando o restore de algum arquivo.
5. No caso do Bacula, preocupe-se demais com o catálogo (que fica no mysql), sem ele você não fará restore dos seus arquivos.

Tar via SSH

Todo mundo tem uma listinha de comandos que ajudam muito no dia a dia. Um dos que mais me ajudam é a cópia de arquivos via SSH. Essa é uma tarefa bem fácil usando o scp, mas quando o volume de arquivos é grande essa transferência pode ficar bem demorada, pra resolver esse problema que tal compactar os arquivos, jogar isso num túnel SSH e já fazer a descompactação no outro lado, da seguinte forma:

tar -czp –same-owner –atime-preserve <arquivo ou diretorio> -f – | ssh usuario@servidor “cd <diretorio_destino> && tar -xzvf -”

As opções do tar podem ser as que você preferir, nesse exemplo, mantem-se as permissões e datas dos arquivos copiados. O segredo para jogar a saida do tar para o ssh é o “-f -”

Slackware com KDE 4.1 e novo logotipo

O Slackware anunciou essa semana duas novidades. A primeira foi a inclusão do KDE 4.1 à árvore do current, (disponível na pasta testing).

Famosa por ser conservadora, a inclusão do KDE 4.1 ao Slackware vem como uma grata notícia. No mesmo anúncio também foi apresentado o novo logotipo do Slackware.

O logotipo é reversível (vire seu monitor de cabeça pra baixo ). Particularmente esse novo logotipo não me agradou, mas se essa ousadia nas novidades se manterem podemos continuar esperando muito dessa distribuição.