Dicas de como melhorar a performance da sua aplicação web começando pelo front-end e depois chegando ao back-end.

1. Melhorando a performance da sua aplicação web Maurício Linhares

3. Instrutor da LinuxFi;

4. Graduado em Desenvolvimento de Software no CEFET-PB;

5. JUGLeader do PBJUG;

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. Meu sistema é assim!

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 humanidade Se você nunca mediu, como é que você sabe que é lento? Lento sempre pode ser rápido o suficiente.

12. 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;

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 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?

15. 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;

16. E você não vai precisar comprar aquele servidor novo Se você quer colocar sua propaganda aqui, ligue para mim!

18. Protocolo simples para troca de documentos na forma de caracteres;

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

21. GET

22. POST

23. HEAD

24. PUT

25. DELETE

26. OPTIONS

27. TRACE

29. 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 (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 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;

31. Anatomia de uma URL Parâmetros Porta Protocolo http://www.google.com.br:80/firefox?client=firefox-a Host Recurso

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

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

36. 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;

37. POST com parâmetros

38. 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;

39. 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;

40. 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;

41. 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

42. 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);

43. 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>

44. 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;

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

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

49. Esqueça isso Não funciona no IEca e é muito tosco

50. 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;

51. 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;

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

55. 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;

58. 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>

59. Se você usa o Apache... <FilesMatch "(gif|jpg|js|css)$"> ExpiresDefault "access plus 10 years" </FilesMatch>

60. 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);

61. Se você usa o Apache... Lembre-se de ativar o mod_deflate AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

64. 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;

65. 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;

66. 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;

67. 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;

68. Exemplo de expressão malvada background-color: expression( (new Date()).getHours( )%2 ? "#B8D4FF" : "#F08A00" );

69. 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;

70. 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;

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

75. 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;

76. 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);

77. 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;

78. 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;

79. 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-Modified FileETagnone </FilesMatch>

80. Depois do front-end... Agora sim nós vamos começar a otimizar aquela query SQL que quase ninguém usa... Ou não

81. 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;

82. 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;

83. 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!

84. Estrutura do balanceamento com um servidor de proxy Tomcat 1 Tomcat 2 Tomcat 3 Proxy

85. 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;

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 assim select * from noticias where titulo like “%tropa% %elite%”

88. Likeconsideredharmful 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;

89. 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...);

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 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!;

92. 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;

93. 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;

94. Em desenho Mestre Escravo 1 Escravo 2 Escravo 3

95. 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;

96. 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;

97. 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 

98. 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;

99. 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;

100. 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);

101. 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;

102. 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;

103. 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;

104. 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;

105. 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;

106. 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;

107. 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á;

108. 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?

109. 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?

110. Primeira lei da distribuição das aplicações Não distribua a sua aplicação

111. 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;

112. 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;

113. 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;

114. fim. Dúvidas? Questões? Reclamações?