Melhorando a performance da sua aplicação webMaurí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 humanidadeSe você nunca mediu, como é que você sabe que é lento?Lento sempre pode ser rápido o suficiente.
Performance de aplicações webPrimeiro, a performance do front-endPáginas;Complementos;ImagensDepois, 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-endPorque 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-endO 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 novoSe você quer colocar sua propaganda aqui, ligue para mim!
O front-end começa no HTTP – HyperTextTransferProtocolProtocolo 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 HTTPO 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 clientefazumarequisiçãoGET /dumprequest.html HTTP/1.1 Host: djce.org.ukUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13Accept: text/htmlAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflateAccept-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-aliveKeep-Alive: 300
E o servidor a responde com um documentoAge: 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 (RedHat) X-Powered-By: PHP/5.1.6 X-AMO-ServedBy: mrapp02 Content-Type: text/html; charset=UTF-8 200 OK[ aquivem o conteúdodapágina ]
Documentossãorequisitadosatravés de URLsUniversal 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 URLParâmetrosPortaProtocolohttp://www.google.com.br:80/firefox?client=firefox-aHostRecurso
O método GETServe 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 GETGET bonitinhohttp://pt.wikipedia.org/wiki/CGIGET feiohttp://www.wscom.com.br//noticia/noticia.jsp?idNoticia=109088GET “Sempre pode ficar pior”http://www.example.com/viewcatalog.asp?category=hats&prodID=53&userType=professor&session=87680jhyumkjj
Método POSTServe 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 HTTPO 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 condicionalUm 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údoO 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-endReceitas 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 HTTPQuanto 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 desvantagensA 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;Inlineimages<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 arquivoJuntar 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 mundoAkamai (todo mundo usa);MirrorImage Internet;Limelight Networks;Amazon S3 – AmazonCloudFront
3 – Adicione um cabeçalho “Expires” a respostaQuando 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 respostaAo 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 componentesUse 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_deflateAddOutputFilterByType DEFLATE text/html text/css application/x-javascript
5 – Coloque a definição das folhas de estilo no inícioAs tags  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ícioColocando 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 fimQuando 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 fimColocar 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 CSSExpressõ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 CSSUma ú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 scriptsVocê 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 DNSSempre 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 scriptsMinificar é 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 redirectsRedirects 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 redirectsEm 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 duplicadosPois é, 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 duplicadosManter 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 cacheadasMesmo 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...<IfModulemod_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 unsetLast-ModifiedFileETagnone</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 cargaA 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;
ApachePadrã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;
NginxServidor 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 proxyTomcat 1Tomcat  2Tomcat  3Proxy
Vantagens do uso de proxiesAs 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 assimselect  * from noticias where titulo like “%tropa% %elite%”
LikeconsideredharmfulBancos 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 textoSe 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?);
LuceneonthewayÉ 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 dadosBancos 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 escravosSe 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 desenhoMestreEscravo 1Escravo 2Escravo 3
Ganhe performance e um prêmio exclusivoAssim 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;
ProblemasA 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 

Melhorando A Performance Da Sua Aplicação Web

  • 1.
    Melhorando a performanceda sua aplicação webMaurício Linhares
  • 2.
  • 3.
  • 4.
    Graduado em Desenvolvimentode Software no CEFET-PB;
  • 5.
  • 6.
    Moderador do GUJ;Deonde 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;
  • 7.
    Performance - wikipediaÉa quantidade de trabalho útil feita por um sistema computacional quando comparada com o tempo e os recursos utilizados
  • 8.
    Ter boa performanceé...Ter um baixo tempo de resposta;Executar muito trabalho em pouco tempo;Utilizar poucos recursos;Estar sempre disponível;
  • 9.
  • 10.
    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?
  • 11.
    Otimização prematura éo mal da humanidadeSe você nunca mediu, como é que você sabe que é lento?Lento sempre pode ser rápido o suficiente.
  • 12.
    Performance de aplicaçõeswebPrimeiro, a performance do front-endPáginas;Complementos;ImagensDepois, a performance do back-end;Bancos de dados;Servidores de aplicação;Serviços de mensageria;
  • 13.
    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...
  • 14.
    Mas programador gostamesmo é de performance de back-endPorque 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?
  • 15.
    Vantagens de sepreocupar primeiro com o front-endO 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;
  • 16.
    E você nãovai precisar comprar aquele servidor novoSe você quer colocar sua propaganda aqui, ligue para mim!
  • 17.
    O front-end começano HTTP – HyperTextTransferProtocolProtocolo desenvolvido pelo W3C e IETF (RFC 2616);
  • 18.
    Protocolo simples paratroca de documentos na forma de caracteres;
  • 19.
    Baseado na idéiade que clientes requisitam um documento a um servidor, que entrega o documento ao cliente;
  • 20.
    O servidor precisaconhecer ou se conectar aos clientes;Os métodos HTTPO protocolo HTTP contém 7 possíveis métodos:
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
    Os navegadores websó implementam GET, POST e HEAD;Primeiro o clientefazumarequisiçãoGET /dumprequest.html HTTP/1.1 Host: djce.org.ukUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13Accept: text/htmlAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflateAccept-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-aliveKeep-Alive: 300
  • 29.
    E o servidora responde com um documentoAge: 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 (RedHat) X-Powered-By: PHP/5.1.6 X-AMO-ServedBy: mrapp02 Content-Type: text/html; charset=UTF-8 200 OK[ aquivem o conteúdodapágina ]
  • 30.
    Documentossãorequisitadosatravés de URLsUniversalResource 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;
  • 31.
    Anatomia de umaURLParâmetrosPortaProtocolohttp://www.google.com.br:80/firefox?client=firefox-aHostRecurso
  • 32.
    O método GETServepara requisitar (GET) um documento (ou arquivo) a um servidor HTTP;
  • 33.
    Um GET NUNCAdeve alterar estados no servidor, deve sempre ser possível fazer duas requisições GET seguidas;
  • 34.
    Um GET podepassar parâmetros para o servidor através de sua URL;
  • 35.
    O tamanho dosparâmetros em um GET é limitado;Exemplos de GETGET bonitinhohttp://pt.wikipedia.org/wiki/CGIGET feiohttp://www.wscom.com.br//noticia/noticia.jsp?idNoticia=109088GET “Sempre pode ficar pior”http://www.example.com/viewcatalog.asp?category=hats&prodID=53&userType=professor&session=87680jhyumkjj
  • 36.
    Método POSTServe paraenviar 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;
  • 37.
  • 38.
    Compressão em HTTPOservidor 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;
  • 39.
    GET condicionalUm clienteHTTP 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;
  • 40.
    Expiração de conteúdoOservidor HTTP é capaz de enviar informações ao cliente avisando em quanto tem um dado recurso (ou documento) deve ser recarregado do servidor;
  • 41.
    As 14 regraspara melhorar a performance da aplicação pelo front-endReceitas de bolo, pronta para usar por qualquer pessoa que saiba operar um fogão ou uma aplicação web
  • 42.
    1 - Façamenos requisições HTTPQuanto 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);
  • 43.
    Use mapas deimagem<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>
  • 44.
    Problemas?Definir todas asposições exatas é uma chatice;Nem sempre dá pra se utilizar um mapa, pois nem sempre as imagens estão juntas;
  • 45.
    CSS Sprites<div style="background-image:url('a_lot_of_sprites.gif'); background-position: -260px -90px; width: 26px; height: 24px;"></div>
  • 46.
    Vantagens e desvantagensAimagem com todas as imagens juntas é menor do que as imagens separadas;
  • 47.
    Você tem queseparar tudo isso em regras de CSS, senão vai criar um cabaré nos links das suas páginas;
  • 48.
    Se o navegadordo cliente estiver com as imagens desabilitadas mas com os estilos habilitados, o resultado são diversos espaços em branco;Inlineimages<IMG ALT="Red Star"SRC="data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWWlvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEAAAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBiatt2H1KBLQRFIJAIKywRgmhwAIlEEADs=">
  • 49.
    Esqueça issoNão funcionano IEca e é muito tosco
  • 50.
    Combinar todos osarquivos de CSS e scripts em um único arquivoJuntar 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;
  • 51.
    2 – Useuma 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;
  • 52.
    2 – Useuma 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;
  • 53.
    CDNs tem hardwaresespecializados em balanceamento e roteamento de carga, você não;
  • 54.
    CDNs vão fazercaching e backup de todo o seu conteúdo sem que você esquente a cabeça com isso;CDNs no mundoAkamai (todo mundo usa);MirrorImage Internet;Limelight Networks;Amazon S3 – AmazonCloudFront
  • 55.
    3 – Adicioneum cabeçalho “Expires” a respostaQuando 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;
  • 56.
    3 – Adicioneum cabeçalho “Expires” a respostaAo 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);
  • 57.
    A primeira cargada 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;
  • 58.
    Problemas...Coloque um númerode 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>
  • 59.
    Se você usao Apache...<FilesMatch "\.(gif|jpg|js|css)$"> ExpiresDefault "access plus 10 years"</FilesMatch>
  • 60.
    4 – Comprimaos componentesUse 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);
  • 61.
    Se você usao Apache...Lembre-se de ativar o mod_deflateAddOutputFilterByType DEFLATE text/html text/css application/x-javascript
  • 62.
    5 – Coloquea definição das folhas de estilo no inícioAs tags que definem uma folha de estilo devem estar sempre no topo da página;
  • 63.
    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ícioColocando 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;
  • 64.
    6 – Coloquescripts no fimQuando 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;
  • 65.
    6 – Coloquescripts no fimColocar 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;
  • 66.
    Problemas...Quando você colocaum 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;
  • 67.
    7 - Eviteexpressões CSSExpressõ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;
  • 68.
    Exemplo de expressãomalvadabackground-color: expression( (new Date()).getHours( )%2 ? "#B8D4FF" : "#F08A00" );
  • 69.
    7 - Eviteexpressões CSSUma ú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;
  • 70.
    8 – Externalizefolhas de estilo e scriptsVocê 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;
  • 71.
    9 – Diminuaas buscas no servidor de DNSSempre 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;
  • 72.
    Configure os seusservidores 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 scriptsMinificar é 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;
  • 73.
    Se você jáestá fazendo compressão, o ganho de ainda minificar o arquivo não é mais tão grande;
  • 74.
    Minificar os arquivosde script deixa eles mais difíceis de serem debugados;11 - Evite redirectsRedirects 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;
  • 75.
    11 - EviteredirectsEm 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;
  • 76.
    12 – Procuree remova estilos e scripts duplicadosPois é, 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);
  • 77.
    12 – Procuree remova estilos e scripts duplicadosManter 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;
  • 78.
    13 – Façarespostas ajax serem cacheadasMesmo 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;
  • 79.
    Se você usao Apache 2...<IfModulemod_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 unsetLast-ModifiedFileETagnone</FilesMatch>
  • 80.
    Depois do front-end...Agorasim nós vamos começar a otimizar aquela query SQL que quase ninguém usa... Ou não
  • 81.
    Balanceie a suacargaA 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;
  • 82.
    ApachePadrã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;
  • 83.
    NginxServidor proxy HTTPextremamente 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!
  • 84.
    Estrutura do balanceamentocom um servidor de proxyTomcat 1Tomcat 2Tomcat 3Proxy
  • 85.
    Vantagens do usode proxiesAs 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;
  • 86.
    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;
  • 87.
    Admita, você jáescreveu uma consulta assimselect * from noticias where titulo like “%tropa% %elite%”
  • 88.
    LikeconsideredharmfulBancos de dadosnã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;
  • 89.
    Indexadores de textoSevocê 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...);
  • 90.
    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?);
  • 91.
    LuceneonthewayÉ o indexadorde 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!;
  • 92.
    Balanceamento de carga2 – O Banco de dadosBancos 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;
  • 93.
    Um senhor deengenho, diversos escravosSe 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;
  • 94.
  • 95.
    Ganhe performance eum prêmio exclusivoAssim 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;
  • 96.
    ProblemasA 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;
  • 97.
    Suporte?Qualquer banco dedados 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 