MELHORANDO A PERFORMANCE DA SUA APLICAÇÃO WEB

Maurício Linhares

Quem sou eu?

Desenvolvedor da CodeVader;

Instrutor da LinuxFi;

Graduado em Desenvolvimento de Software no CEFET-PB;

JUGLeader do PBJUG;

Moderador do GUJ;

De onde vem isso?

Souders, Steve. High Performance Web Sites. O`Reilly, 2007;

Henderson, Cal. Building Highly Scalable Web Sites. O`Reilly, 2006;

Vários autores. High Performance MySQL. O`Reilly, 2008;

PERFORMANCE - WIKIPEDIA

É a quantidade de trabalho útil feita por um sistema computacional quando comparada com o tempo e os recursos utilizados

Ter boa performance é...

Ter um baixo tempo de resposta;

Executar muito trabalho em pouco tempo;

Utilizar poucos recursos;

Estar sempre disponível;

Meu sistema é assim!

Antes de começar...

Você realmente precisa de alta performance?

Você já mediu a sua performance atual?

Você já mediu a carga que você vai precisar servir?

OTIMIZAÇÃO PREMATURA É O MAL DA HUMANIDADE

Se você nunca mediu, como é que você sabe que é lento?

Lento sempre pode ser rápido o suficiente.

Performance de aplicações web Primeiro, a performance do front-end

Páginas; Complementos; Imagens

Depois, a performance do back-end; Bancos de dados; Servidores de aplicação; Serviços de mensageria;

Performance do front-end

É a performance da interface gráfica das suas aplicações web (sabe, aquela coisa que aparece no navegador e tal...);

É a performance mais percebida pelos usuários do seu sistema;

Normalmente, é a performance mais fácil de ser melhorada...

MAS PROGRAMADOR GOSTA MESMO É DE PERFORMANCE DE BACK-END

Porque diminuir o tamanho de uma página web se eu posso melhorar a performance dessa consulta SQL que é chamada de quando em nunca no meu sistema?

Vantagens de se preocupar primeiro com o front-end O seu usuário fica feliz antes;

A sua aplicação normalmente não sofre cirurgias plásticas ;

Os resultados são imediatos, mesmo que hajam alguns efeitos colaterais;

E você não vai precisar comprar aquele servidor novo

Se você quer colocar sua propaganda aqui, ligue para mim!

O front-end começa no HTTP – Hyper Text Transfer Protocol Protocolo desenvolvido pelo W3C e IETF (RFC

2616);

Protocolo simples para troca de documentos na forma de caracteres;

Baseado na idéia de que clientes requisitam um documento a um servidor, que entrega o documento ao cliente;

O servidor precisa conhecer ou se conectar aos clientes;

Os métodos HTTP

O protocolo HTTP contém 7 possíveis métodos: GET POST HEAD PUT DELETE OPTIONS TRACE

Os navegadores web só implementam GET, POST e HEAD;

Primeiro o cliente faz uma requisição

GET /dumprequest.html HTTP/1.1 Host: djce.org.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT

6.0; pt-BR; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

Accept: text/htmlAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflate Accept-Language: pt-br,pt;q=0.8,en-

us;q=0.5,en;q=0.3 Referer: http://www.google.com.br/search Connection: keep-alive Keep-Alive: 300

E o servidor a responde com um documento

Age: 3066 Date: Fri, 18 Apr 2008 19:56:55 GMT Content-Length: 21104 Via: NS-CACHE-6.1: 1 Etag: "KXBLIJGJEBZKLZPUS" Server: Apache/2.2.3 (Red Hat) X-Powered-By: PHP/5.1.6 X-AMO-ServedBy: mrapp02 Content-Type: text/html; charset=UTF-8 200 OK

[ aqui vem o conteúdo da página ]

Documentos são requisitados através de URLs

Universal Resource Locator;

É uma forma simples e fácil de se definir um recurso de forma que ele seja único;

Utilizado também em sistemas de arquivos;

Anatomia de uma URL

http://www.google.com.br:80/firefox?client=firefox-a

Protocolo

Host

Porta

Recurso

Parâmetros

O método GET

Serve para requisitar (GET) um documento (ou arquivo) a um servidor HTTP;

Um GET NUNCA deve alterar estados no servidor, deve sempre ser possível fazer duas requisições GET seguidas;

Um GET pode passar parâmetros para o servidor através de sua URL;

O tamanho dos parâmetros em um GET é limitado;

Exemplos de GET

GET bonitinho http://pt.wikipedia.org/wiki/CGI

GET feio http://www.wscom.com.br//noticia/notici

a.jsp?idNoticia=109088 GET “Sempre pode ficar pior”

http://www.example.com/viewcatalog.asp?category=hats&prodID=53&userType=professor&session=87680jhyumkjj

Método POST

Serve para enviar dados para o servidor HTTP;

Um POST pode fazer alteração em dados do servidor;

Os parâmetros do POST vão no corpo da requisição e não na URL;

Não existem limitações quanto ao tamanho dos parâmetros enviados em um POST;

POST com parâmetros

Compressão em HTTP

O servidor HTTP pode comprimir a resposta para o cliente, diminuindo o tamanho dos dados que vão trafegar pela rede;

O servidor normalmente só comprime quando o cliente é capaz de entender o conteúdo compresso;

GET condicional

Um cliente HTTP pode ser capaz de fazer um GET “condicional”, recebendo um novo documento apenas se o documento que ele tem em cache estiver desatualizado;

A maior parte dos navegadores web são capazes de manter recursos em cache e fazer GETs condicionais;

Expiração de conteúdo

O servidor HTTP é capaz de enviar informações ao cliente avisando em quanto tem um dado recurso (ou documento) deve ser recarregado do servidor;

AS 14 REGRAS PARA MELHORAR A PERFORMANCE DA APLICAÇÃO PELO FRONT-END

Receitas de bolo, pronta para usar por qualquer pessoa que saiba operar um fogão ou uma aplicação web

1 - Faça menos requisições HTTP

Quanto menos requisições uma página faz:

Mais rápido ela é carregada pelo cliente; Menos carga ela gera no servidor; Menos banda de rede ela usa (conexões

TCP são caras);

Use mapas de imagem

<img usemap="#map1" border=0 src="/images/imagemap.gif"><map name="map1"> <area shape="rect" coords="0,0,31,31" href="home.html" title="Home"> <area shape="rect" coords="36,0,66,31" href="gifts.html" title="Gifts"> <area shape="rect" coords="71,0,101,31" href="cart.html" title="Cart"> <area shape="rect" coords="106,0,136,31" href="settings.html" title="Settings"> <area shape="rect" coords="141,0,171,31" href="help.html" title="Help"></map>

Problemas?

Definir todas as posições exatas é uma chatice;

Nem sempre dá pra se utilizar um mapa, pois nem sempre as imagens estão juntas;

CSS Sprites

<div style="background-image: url('a_lot_of_sprites.gif'); background-position: -260px -90px; width: 26px; height: 24px;"></div>

Vantagens e desvantagens

A imagem com todas as imagens juntas é menor do que as imagens separadas;

Você tem que separar tudo isso em regras de CSS, senão vai criar um cabaré nos links das suas páginas;

Se o navegador do cliente estiver com as imagens desabilitadas mas com os estilos habilitados, o resultado são diversos espaços em branco;

Inline images

<IMG ALT="Red Star"SRC="data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWWlvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEAAAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBiatt2H1KBLQRFIJAIKywRgmhwAIlEEADs=">

ESQUEÇA ISSONão funciona no IEca e é muito tosco

Combinar todos os arquivos de CSS e scripts em um único arquivo Juntar todos os arquivos CSS da

aplicação em apenas um;

Juntar todos os arquivos de script da aplicação também em um único arquivo;

2 – Use uma rede de entrega de conteúdo (CDN) Os seus arquivos que são estáticos

são servidos pela CDN;

A CDN normalmente tem servidores espalhados geograficamente, com mais chances de estarem perto do seu usuário do que aquele seu servidor alugado na Estônia pra uma aplicação usada na Paraíba;

2 – Use uma rede de entrega de conteúdo (CDN) Estando mais próxima do cliente, a latência

e as chances de falha na rede são menores;

CDNs tem hardwares especializados em balanceamento e roteamento de carga, você não;

CDNs vão fazer caching e backup de todo o seu conteúdo sem que você esquente a cabeça com isso;

CDNs no mundo

Akamai (todo mundo usa);

Mirror Image Internet;

Limelight Networks;

Amazon S3 – Amazon CloudFront

3 – Adicione um cabeçalho “Expires” a resposta Quando um cliente acessa a sua

página, ele vai fazer a carga não só da página, mas também dos componentes dela;

O navegador vai carregar os recursos e manter eles em cache, mas quando a próxima requisição acontecer, ele vai chegar se precisa atualizar todos os recursos que foram carregados;

3 – Adicione um cabeçalho “Expires” a resposta Ao adicionar um cabeçalho “Expires” em

um tempo no futuro distante (como 1 de janeiro de 2020) você garante que o navegador não ai mais fazer uma requisição para aquele recurso até essa data (assim, fazendo menos requisições HTTP);

A primeira carga da página pode ser lenta, mas as subseqüentes vão ser muito mais rápidas;

Problemas...

Quando você coloca um cabeçalho “Expires” para um futuro distante e depois altera o arquivo (sem mudar o seu nome) o navegador que havia feito o cache desse recurso nunca vai receber a atualização, a não ser que ele limpe o seu cache;

Problemas...

Coloque um número de versão em todos os arquivos que vão alterar com frequência (como folhas de estilo e scrips):

<script src="test.2.0.0.js"></script>

Se você usa o Apache...

<FilesMatch "\.(gif|jpg|js|css)$">ExpiresDefault "access plus 10 years"

</FilesMatch>

4 – Comprima os componentes Use compressão em tudo o que

puder ser utilizado na sua página (desde recursos até a própria página);

A compressão ajuda a diminuir significativamente o tamanho de arquivos de texto (espaços em branco normalmente são ignorados em HTML, CSS e JavaScript);

Se você usa o Apache...

Lembre-se de ativar o mod_deflate

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

5 – Coloque a definição das folhas de estilo no início As tags <link> que definem uma folha de

estilo devem estar sempre no topo da página;

Os navegadores web (mais especificamente o IEca) só começam a renderizar a página se eles acharem que não vão mais haver alterações no design, se eles encontrarem ma folha de estilos ainda não carregada, eles vão parar a renderização e esperar a folha de estilos carregar;

5 – Coloque a definição das folhas de estilo no início Colocando as folhas de estilo no topo

da página, faz com que elas sejam carregadas antes e a página comece também a ser renderizada mais cedo;

Isso não afeta a performance real da aplicação, apenas a performance percebida pelo cliente;

6 – Coloque scripts no fim Quando um navegador web encontra

uma tag <script> que indica um script externo, ele pára de renderizar a página até que o arquivo de script seja carregado;

Apenas depois que o arquivo de script é carregado e executado, o navegador dá continuidade a execução e carga de novos componentes para a página;

6 – Coloque scripts no fim Colocar scripts no início (ou pior, no

meio) de uma página pode deixar ela lenta do ponto de vista do cliente, pois quando o script vai ser carregado, toda a página fica “em espera”;

Colocados no final, o usuário vai ver a página toda antes do script começar a executar;

Problemas...

Quando você coloca um script no final da página, você está também adiando a definição de funções que você usa nela, se o cliente clicar ou tentar executar alguma ação que depende de um script, o componente não vai responder com nada, pois o script pode não ter sido carregado ainda;

7 - Evite expressões CSS

Expressões CSS foram uma “novidade” trazida pelo IEca 5;

Elas são avaliadas sempre que: A página tem o seu tamanho alterado; O usuário faz scroll na página; O usuário passa o mouse pela página;

Exemplo de expressão malvadabackground-color: expression( (new

Date()).getHours( )%2 ? "#B8D4FF" : "#F08A00" );

7 - Evite expressões CSS

Uma única expressão CSS pode ser avaliada mais de 10.000 vezes apenas com algumas passadas ou mouse pela página (e o seu cliente com aquele pentium 4...) ;

Apenas o IEca tem suporte de verdade pra isso, então você não deveria estar usando mesmo;

8 – Externalize folhas de estilo e scripts Você deve evitar a definição de

scrips e estilos dentro da página HTML, pois esse conteúdo vai sempre ocupar espaço e gastar banda de rede, quando ele poderia estar em um arquivo externo e cacheado pelo navegador;

Definir funções e estilos dentro das páginas também dificulta o reuso e dá espaço pra duplicação de código;

9 – Diminua as buscas no servidor de DNS Sempre que um navegador acessa uma

página por um nome de domínio, ele precisa encontrar o IP real perguntando a um servidor de DNS e isso custa tempo;

Configure os seus servidores de DNS de forma que eles dêem uma duração maior ao resultado retornado, de forma que o cliente não precise ficar “perguntando” qual o IP do servidor o tempo todo;

10 – Faça a “minificação” dos seus scripts Minificar é remover todos os caracteres que

representam espaços em branco de um arquivo, remover os espaços em branco de um arquivo de script normalmente diminui e muito o tamanho do arquivo;

Se você já está fazendo compressão, o ganho de ainda minificar o arquivo não é mais tão grande;

Minificar os arquivos de script deixa eles mais difíceis de serem debugados;

11 - Evite redirects

Redirects deixam as suas páginas mais lentas (se o seu servidor trabalhando mais) por um simples motivo, você está obrigando o cliente a fazer uma nova requisição do zero;

Se você pode retornar a página diretamente, evite fazer o redirect, você poupa o cliente e o seu servidor do trabalho;

11 - Evite redirects

Em Java, por exemplo, você pode usar um forward() dentro de um servlet, ou incluir a página que seria redirecionada em PHP;

Cuidado ao evitar redirects após o envio de dados por um formulário, você sempre deve redirecionar após receber os dados via POST em um formulário;

12 – Procure e remova estilos e scripts duplicados Pois é, eles existem, duas páginas

podem usar o mesmo script e estarem apontando para arquivos diferentes (e que serão cacheados como sendo arquivos diferentes);

Faça com que todas as páginas apontem sempre para os mesmos scripts e as mesmas folhas de estilo (crie pastas padronizadas para colocar os scripts e os estilos);

12 – Procure e remova estilos e scripts duplicados Manter tudo em um único lugar

facilita a vida do navegador, que vai poder reutilizar os estilos para todas as páginas que os usem;

E também vai facilitar a vida dos desenvolvedores que vão realmente reutilizar o que já foi feito;

13 – Faça respostas ajax serem cacheadas Mesmo em respostas a requisições

AJAX você deve se preocupar com o cache de informações;

Sempre que possível, faça respostas AJAX serem cacheadas, assim como páginas web;

Se você usa o Apache 2...

<IfModule mod_deflate.c> <FilesMatch "\.(js|css)$"> SetOutputFilter DEFLATE </FilesMatch></IfModule>

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> Header set Cache-Control "public" Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT" Header unset Last-Modified FileETag none</FilesMatch>

DEPOIS DO FRONT-END...

Agora sim nós vamos começar a otimizar aquela query SQL que quase ninguém usa... Ou não

Balanceie a sua carga

A regra é a de sempre, dividir para conquistar, divida a carga do seu servidor web em diferentes servidores de aplicação;

Balanceamento de carga oferece um presente de brinde, resistência a falhas (fail-over);

Existem ferramentas aos borbotões pra se fazer isso;

Apache

Padrão de mercado, todo mundo usa, todo mundo conhece;

Diversos módulos com funcionalidades que você nem sabia que precisava;

Roda em qualquer banheira;

Grande demais pra resolver um problema tão pequeno;

Nginx

Servidor proxy HTTP extremamente enxuto e desconhecido, vindo diretamente da terra dos Czares;

Leve, rápido e eficiente pra entrega de conteúdo estático e proxying;

Windows? Nunca será!

Você já tinha ouvido falar nele? Nem eu!

Estrutura do balanceamento com um servidor de proxy

Proxy

Tomcat 1

Tomcat 2

Tomcat 3

Vantagens do uso de proxies As requisições sempre são entregues para

um servidor que está “vivo”;

O servidor de proxy pode entregar recursos estáticos que estão nos servidores de aplicação sem nem falar com eles;

O servidor de proxy pode executar trabalhos custosos como compressão sem causar problemas aos servidores de aplicação;

Bancos de dados? Mas já?

Crie índices para todas as colunas que forem pesquisáveis;

Remova índices de todas as colunas que não são realmente pesquisáveis;

Use o profiler do seu banco para encontrar consultas que demoram para executar;

Contrate um DBA;

ADMITA, VOCÊ JÁ ESCREVEU UMA CONSULTA ASSIM

select * from noticias where titulo like “%tropa% %elite%”

Like considered harmful

Bancos de dados não são bons em buscas por texto, especialmente quando você usa os ainda mais malvados caracteres curinga ( como “%” e “*” );

Índices para campos de texto de muitos caracteres (TEXT ou CLOB) são um mal sem igual;

Indexadores de texto

Se você realmente precisa daquele like, que você precisa é de um indexador de texto;

Um indexador de texto (como o Google, conhece?), é uma ferramenta especializada em organizar e buscar documentos contendo texto;

Ele contém otimizações específicas para buscas em texto, como ignorar palavras sem importância (preposições, pronomes, artigos...);

Você quis dizer “banco de dados”? Eles são capazes, inclusive, de inferir

outras palavras ou resultados através dos dados que você forneceu, porque eles entendem também de formação de palavras (lembra daquela aula de português sobre radicais?);

Lucene on the way

É o indexador de texto mais utilizado no mundo, escrito em Java mas com versões também em C, Ruby, Python e você pode escrever a sua;

Mantido pela fundação Apache, com muita documentação e livros disponíveis;

Está sendo utilizado como base para o indexador Hadoop do Yahoo!;

Balanceamento de carga 2 – O Banco de dados Bancos de dados também podem se

utilizar de técnicas de balanceamento de carga, como os servidores web, mas aqui o problema é bem maior;

O maior problema é fazer com que ninguém leia dados inválidos ou desatualizados;

Um senhor de engenho, diversos escravos Se você tem uma aplicação que faz

mais leituras do que escritas, pode definir um banco como sendo o banco “mestre” e fazer todas as escritas nele;

Você agora pode, definir vários bancos “escravos” que se atualizam baseados no banco “mestre” e recebem todas as consultas;

Em desenho

Mestre

Escravo 1

Escravo 2

Escravo 3

Ganhe performance e um prêmio exclusivo Assim como nos servidores web, com

um banco mestre e diversos escravos, se um dos escravos morrer, a aplicação pode continuar se conectando aos que ainda estão vivos, ela não falha quando um banco escravo falha;

É uma ótima opção para criar bancos de “relatórios”, pois você roda aquelas consultas intermináveis e não mata o servidor principal;

Problemas

A atualização não é instantânea, se você precisa estar atualizado 100% do tempo, isso não serve pra você;

Quando mais escravos, mais comunicação a rede vai ter que aguentar, então tenha um link rápido;

Se o master falhar, você fica impossibilitado de escrever qualquer coisa;

Suporte?

Qualquer banco de dados com o mínimo de decência suporta isso;

Se o seu banco não suporta isso diretamente, use uma ferramenta de replicação que ele tenha e seja feliz (se ele não tiver...);

Use o MySQL e seja feliz

Espalhando o banco de dados em diversos bancos Se o master-slave não funciona, você

pode tentar sharding, que é espalhar os dados em diversos bancos de dados diferentes;

Você pode colocar tabelas ou conjuntos de tabelas muito consultadas ou alteradas em uma máquina separada das demais, de forma que ela apenas se preocupe com os dados dessas tabelas;

Sharding por características Você também pode fazer sharding

pelas características dos dados ( “Notícia do Brasil? manda pra aquele servidor em Mali” );

Assim você pode agrupar dados baseado nas informações deles, como separar os clientes de um país em um servidor mais próximo a eles;

Problemas?

É o modelo mais difícil de ser implementado, passe pra isso quando você realmente não tiver mais opções;

Existem poucas ferramentas disponíveis pra lhe ajudar nesse serviço ( um projeto em Java, o Hibernate Shards, oferece um suporte rudimentar a solução);

O melhor é não chegar no banco de dados A melhor otimização para banco de

dados, é simplesmente não chegar no banco de dados, se você não fizer uma consulta, ele não se ocupa;

Se você tem um tráfego muito alto e com uma frequência muito alta, manter dados em um cache em memória é bem mais interessante;

Caches em memória para bancos de dados A sua aplicação pode evitar consultar

o banco de dados usando caches em memória ou até mesmo em disco;

Você faz uma consulta no banco de dados uma vez, coloca ela no cache e só vai no banco de dados de novo quando essa consulta precisar ser atualizada;

Caches em memória

Os caches em memória não precisam ser necessariamente para bancos de dados, você pode usar eles pra qualquer dado que seja demorado de se produzir (como ler de arquivos ou acessar servidores externos via web services);

Existe uma infinidade de opções em todas as linguagens de programação;

Se você está em Java...

...e usa o Hibernate!

Ele tem suporte direto a ferramentas de cache para consultas no banco de dados, tanto para caches locais como para caches distribuídos;

Você normalmente não precisa alterar o seu código que já funciona pra se aproveitar disso;

Em um mundo sem Java

Memcached é a solução;

Um servidor de cache de objetos remoto, simples, fácil de usar e com bindings pra qualquer linguagem de programação;

Desenvolvido originalmente pelo pessoal do LiveJournal pra aguentar o tranco do site deles;

Memcached

Você se conecta no servidor, manda um objeto para o cache, atribui uma chave a ele;

Depois, você usa essa chave pra descobrir se o objeto está lá, se ele estiver, ele é retornado, se ele não estiver, você vai no banco de dados (ou na fonte dos dados) e busca ele, colocando ele no cache;

Memcached e distribuição

O memcached não é distribuído, cada servidor opera sozinho, eles não se comunicam entre si, se você quer diversos servidores, trate de configurar as suas conexões ao servidor de forma inteligente;

Trate o cache como a fonte preferencial, mas lembre-se que o objeto pode não estar lá;

Avaliando a utilização de um cache Será que o cache está ajudando?

Quantas vezes você acerta o cache?

Quantas vezes o dado está lá?

O dado é atualizado muitas vezes?

Quem disse que você precisa de uma ferramenta dessas?

Distribuição de aplicações Em todos os nossos casos, a

aplicação toda é movida para um novo servidor, de forma que ela possa receber a carga dos clientes;

Tem gente que diz que você pode quebrar a sua aplicação em pequenos pedaços e assim diminuir a carga de cada um dos pedaços;

Você consegue ver um problema nisso?

PRIMEIRA LEI DA DISTRIBUIÇÃO DAS APLICAÇÕES

Não distribua a sua aplicação

Problemas?

Redes falham;

Máquinas falham;

Pessoas que pisam em fios de energia falham;

Cada “pequena” aplicação é o seu próprio mundo, com todos os mesmos problemas que nós falamos anteriormente;

Mas isso não serve pra nada? Em um mundo ideal, cada aplicação

seria na verdade um pequeno pedaço de um sistema, vivendo sozinha no mundo, se comunicando com outros apenas quando necessário;

Mas isso não pode ser usado como meio para se conseguir performance ou aumentar a “produtividade” de um sistema;

Mas isso não serve pra nada? Simplesmente distribuir esperando por

ganhos costuma causar muito mais problemas (multiplicados por cada “mini-aplicação”) do que resolver os que você já tem;

A divisão de um grande sistema em pequenos sistemas deve ser uma coisa planejada e pensada com antecedência, não uma resposta ao cliente alucinado por não conseguir usá-lo;

FIM.

Dúvidas? Questões? Reclamações?