Melhorando A Performance Da Sua Aplicação Web

6,097 views

Published on

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

Published in: Technology
4 Comments
10 Likes
Statistics
Notes
No Downloads
Views
Total views
6,097
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
165
Comments
4
Likes
10
Embeds 0
No embeds

No notes for slide

Melhorando A Performance Da Sua Aplicação Web

  1. 1. Melhorando a performance da sua aplicação web<br />Maurício Linhares<br />
  2. 2. Quem sou eu?<br /><ul><li>Desenvolvedor da CodeVader;
  3. 3. Instrutor da LinuxFi;
  4. 4. Graduado em Desenvolvimento de Software no CEFET-PB;
  5. 5. JUGLeader do PBJUG;
  6. 6. Moderador do GUJ;</li></li></ul><li>De onde vem isso?<br />Souders, Steve. High Performance Web Sites. O`Reilly, 2007;<br />Henderson, Cal. Building Highly Scalable Web Sites. O`Reilly, 2006;<br />Vários autores. High Performance MySQL. O`Reilly, 2008;<br />
  7. 7. Performance - wikipedia<br />É a quantidade de trabalho útil feita por um sistema computacional quando comparada com o tempo e os recursos utilizados<br />
  8. 8. Ter boa performance é...<br />Ter um baixo tempo de resposta;<br />Executar muito trabalho em pouco tempo;<br />Utilizar poucos recursos;<br />Estar sempre disponível;<br />
  9. 9. Meu sistema é assim!<br />
  10. 10. Antes de começar...<br />Você realmente precisa de alta performance?<br />Você já mediu a sua performance atual?<br />Você já mediu a carga que você vai precisar servir?<br />
  11. 11. Otimização prematura é o mal da humanidade<br />Se você nunca mediu, como é que você sabe que é lento?<br />Lento sempre pode ser rápido o suficiente.<br />
  12. 12. Performance de aplicações web<br />Primeiro, a performance do front-end<br />Páginas;<br />Complementos;<br />Imagens<br />Depois, a performance do back-end;<br />Bancos de dados;<br />Servidores de aplicação;<br />Serviços de mensageria;<br />
  13. 13. Performance do front-end<br />É a performance da interface gráfica das suas aplicações web (sabe, aquela coisa que aparece no navegador e tal...);<br />É a performance mais percebida pelos usuários do seu sistema;<br />Normalmente, é a performance mais fácil de ser melhorada...<br />
  14. 14. Mas programador gosta mesmo é de performance de back-end<br />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?<br />
  15. 15. Vantagens de se preocupar primeiro com o front-end<br />O seu usuário fica feliz antes;<br />A sua aplicação normalmente não sofre cirurgias plásticas ;<br />Os resultados são imediatos, mesmo que hajam alguns efeitos colaterais;<br />
  16. 16. E você não vai precisar comprar aquele servidor novo<br />Se você quer colocar sua propaganda aqui, ligue para mim!<br />
  17. 17. O front-end começa no HTTP – HyperTextTransferProtocol<br /><ul><li>Protocolo desenvolvido pelo W3C e IETF (RFC 2616);
  18. 18. Protocolo simples para troca de documentos na forma de caracteres;
  19. 19. Baseado na idéia de que clientes requisitam um documento a um servidor, que entrega o documento ao cliente;
  20. 20. O servidor precisa conhecer ou se conectar aos clientes;</li></li></ul><li>Os métodos HTTP<br /><ul><li>O protocolo HTTP contém 7 possíveis métodos:
  21. 21. GET
  22. 22. POST
  23. 23. HEAD
  24. 24. PUT
  25. 25. DELETE
  26. 26. OPTIONS
  27. 27. TRACE
  28. 28. Os navegadores web só implementam GET, POST e HEAD;</li></li></ul><li>Primeiro o clientefazumarequisição<br />GET /dumprequest.html HTTP/1.1 <br />Host: djce.org.uk<br />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<br />Accept: text/html<br />Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 <br />Accept-Encoding: gzip,deflate<br />Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 <br />Referer: http://www.google.com.br/search <br />Connection: keep-aliveKeep-Alive: 300<br />
  29. 29. E o servidor a responde com um documento<br />Age: 3066 Date: Fri, 18 Apr 2008 19:56:55 GMT <br />Content-Length: 21104 <br />Via: NS-CACHE-6.1: 1 <br />Etag: &quot;KXBLIJGJEBZKLZPUS&quot; <br />Server: Apache/2.2.3 (RedHat) <br />X-Powered-By: PHP/5.1.6 <br />X-AMO-ServedBy: mrapp02 <br />Content-Type: text/html; charset=UTF-8 200 OK<br />[ aquivem o conteúdodapágina ]<br />
  30. 30. Documentossãorequisitadosatravés de URLs<br />Universal Resource Locator;<br />É uma forma simples e fácil de se definir um recurso de forma que ele seja único;<br />Utilizado também em sistemas de arquivos;<br />
  31. 31. Anatomia de uma URL<br />Parâmetros<br />Porta<br />Protocolo<br />http://www.google.com.br:80/firefox?client=firefox-a<br />Host<br />Recurso<br />
  32. 32. O método GET<br /><ul><li>Serve para requisitar (GET) um documento (ou arquivo) a um servidor HTTP;
  33. 33. Um GET NUNCA deve alterar estados no servidor, deve sempre ser possível fazer duas requisições GET seguidas;
  34. 34. Um GET pode passar parâmetros para o servidor através de sua URL;
  35. 35. O tamanho dos parâmetros em um GET é limitado;</li></li></ul><li>Exemplos de GET<br />GET bonitinho<br />http://pt.wikipedia.org/wiki/CGI<br />GET feio<br />http://www.wscom.com.br//noticia/noticia.jsp?idNoticia=109088<br />GET “Sempre pode ficar pior”<br />http://www.example.com/viewcatalog.asp?category=hats&prodID=53&userType=professor&session=87680jhyumkjj<br />
  36. 36. Método POST<br />Serve para enviar dados para o servidor HTTP;<br />Um POST pode fazer alteração em dados do servidor;<br />Os parâmetros do POST vão no corpo da requisição e não na URL;<br />Não existem limitações quanto ao tamanho dos parâmetros enviados em um POST;<br />
  37. 37. POST com parâmetros<br />
  38. 38. Compressão em HTTP<br />O servidor HTTP pode comprimir a resposta para o cliente, diminuindo o tamanho dos dados que vão trafegar pela rede;<br />O servidor normalmente só comprime quando o cliente é capaz de entender o conteúdo compresso;<br />
  39. 39. GET condicional<br />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;<br />A maior parte dos navegadores web são capazes de manter recursos em cache e fazer GETs condicionais;<br />
  40. 40. Expiração de conteúdo<br />O servidor HTTP é capaz de enviar informações ao cliente avisando em quanto tem um dado recurso (ou documento) deve ser recarregado do servidor;<br />
  41. 41. As 14 regras para melhorar a performance da aplicação pelo front-end<br />Receitas de bolo, pronta para usar por qualquer pessoa que saiba operar um fogão ou uma aplicação web<br />
  42. 42. 1 - Faça menos requisições HTTP<br />Quanto menos requisições uma página faz:<br />Mais rápido ela é carregada pelo cliente;<br />Menos carga ela gera no servidor;<br />Menos banda de rede ela usa (conexões TCP são caras);<br />
  43. 43. Use mapas de imagem<br />&lt;img usemap=&quot;#map1&quot; border=0 src=&quot;/images/imagemap.gif&quot;&gt;<br />&lt;map name=&quot;map1&quot;&gt;<br /> &lt;area shape=&quot;rect&quot; coords=&quot;0,0,31,31&quot; href=&quot;home.html&quot; title=&quot;Home&quot;&gt;<br /> &lt;area shape=&quot;rect&quot; coords=&quot;36,0,66,31&quot; href=&quot;gifts.html&quot; title=&quot;Gifts&quot;&gt;<br /> &lt;area shape=&quot;rect&quot; coords=&quot;71,0,101,31&quot; href=&quot;cart.html&quot; title=&quot;Cart&quot;&gt;<br /> &lt;area shape=&quot;rect&quot; coords=&quot;106,0,136,31&quot; href=&quot;settings.html&quot; title=&quot;Settings&quot;&gt;<br /> &lt;area shape=&quot;rect&quot; coords=&quot;141,0,171,31&quot; href=&quot;help.html&quot; title=&quot;Help&quot;&gt;<br />&lt;/map&gt;<br />
  44. 44. Problemas?<br />Definir todas as posições exatas é uma chatice;<br />Nem sempre dá pra se utilizar um mapa, pois nem sempre as imagens estão juntas;<br />
  45. 45. CSS Sprites<br />&lt;div style=&quot;background-image: url(&apos;a_lot_of_sprites.gif&apos;);<br /> background-position: -260px -90px;<br /> width: 26px; height: 24px;&quot;&gt;<br />&lt;/div&gt;<br />
  46. 46. Vantagens e desvantagens<br /><ul><li>A imagem com todas as imagens juntas é menor do que as imagens separadas;
  47. 47. Você tem que separar tudo isso em regras de CSS, senão vai criar um cabaré nos links das suas páginas;
  48. 48. Se o navegador do cliente estiver com as imagens desabilitadas mas com os estilos habilitados, o resultado são diversos espaços em branco;</li></li></ul><li>Inlineimages<br />&lt;IMG ALT=&quot;Red Star&quot;<br />SRC=&quot;data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWW<br />lvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEA<br />AAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBia<br />tt2H1KBLQRFIJAIKywRgmhwAIlEEADs=&quot;&gt;<br />
  49. 49. Esqueça isso<br />Não funciona no IEca e é muito tosco<br />
  50. 50. Combinar todos os arquivos de CSS e scripts em um único arquivo<br />Juntar todos os arquivos CSS da aplicação em apenas um;<br />Juntar todos os arquivos de script da aplicação também em um único arquivo;<br />
  51. 51. 2 – Use uma rede de entrega de conteúdo (CDN)<br />Os seus arquivos que são estáticos são servidos pela CDN;<br />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;<br />
  52. 52. 2 – Use uma rede de entrega de conteúdo (CDN)<br /><ul><li>Estando mais próxima do cliente, a latência e as chances de falha na rede são menores;
  53. 53. CDNs tem hardwares especializados em balanceamento e roteamento de carga, você não;
  54. 54. CDNs vão fazer caching e backup de todo o seu conteúdo sem que você esquente a cabeça com isso;</li></li></ul><li>CDNs no mundo<br />Akamai (todo mundo usa);<br />MirrorImage Internet;<br />Limelight Networks;<br />Amazon S3 – AmazonCloudFront<br />
  55. 55. 3 – Adicione um cabeçalho “Expires” a resposta<br />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;<br />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;<br />
  56. 56. 3 – Adicione um cabeçalho “Expires” a resposta<br /><ul><li>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);
  57. 57. A primeira carga da página pode ser lenta, mas as subseqüentes vão ser muito mais rápidas;</li></li></ul><li>Problemas...<br />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;<br />
  58. 58. Problemas...<br />Coloque um número de versão em todos os arquivos que vão alterar com frequência (como folhas de estilo e scrips):<br />&lt;script src=&quot;test.2.0.0.js&quot;&gt;&lt;/script&gt;<br />
  59. 59. Se você usa o Apache...<br />&lt;FilesMatch &quot;.(gif|jpg|js|css)$&quot;&gt;<br /> ExpiresDefault &quot;access plus 10 years&quot;<br />&lt;/FilesMatch&gt;<br />
  60. 60. 4 – Comprima os componentes<br />Use compressão em tudo o que puder ser utilizado na sua página (desde recursos até a própria página);<br />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);<br />
  61. 61. Se você usa o Apache...<br />Lembre-se de ativar o mod_deflate<br />AddOutputFilterByType DEFLATE text/html text/css application/x-javascript<br />
  62. 62. 5 – Coloque a definição das folhas de estilo no início<br /><ul><li>As tags <link> que definem uma folha de estilo devem estar sempre no topo da página;
  63. 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;</li></li></ul><li>5 – Coloque a definição das folhas de estilo no início<br />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;<br />Isso não afeta a performance real da aplicação, apenas a performance percebida pelo cliente;<br />
  64. 64. 6 – Coloque scripts no fim<br />Quando um navegador web encontra uma tag &lt;script&gt; que indica um script externo, ele pára de renderizar a página até que o arquivo de script seja carregado;<br />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;<br />
  65. 65. 6 – Coloque scripts no fim<br />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”;<br />Colocados no final, o usuário vai ver a página toda antes do script começar a executar;<br />
  66. 66. Problemas...<br />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;<br />
  67. 67. 7 - Evite expressões CSS<br />Expressões CSS foram uma “novidade” trazida pelo IEca 5;<br />Elas são avaliadas sempre que:<br />A página tem o seu tamanho alterado;<br />O usuário faz scroll na página;<br />O usuário passa o mouse pela página;<br />
  68. 68. Exemplo de expressão malvada<br />background-color: expression( (new Date()).getHours( )%2 ? &quot;#B8D4FF&quot; : &quot;#F08A00&quot; );<br />
  69. 69. 7 - Evite expressões CSS<br />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...) ;<br />Apenas o IEca tem suporte de verdade pra isso, então você não deveria estar usando mesmo;<br />
  70. 70. 8 – Externalize folhas de estilo e scripts<br />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;<br />Definir funções e estilos dentro das páginas também dificulta o reuso e dá espaço pra duplicação de código;<br />
  71. 71. 9 – Diminua as buscas no servidor de DNS<br /><ul><li>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;
  72. 72. 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;</li></li></ul><li>10 – Faça a “minificação” dos seus scripts<br /><ul><li>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;
  73. 73. Se você já está fazendo compressão, o ganho de ainda minificar o arquivo não é mais tão grande;
  74. 74. Minificar os arquivos de script deixa eles mais difíceis de serem debugados;</li></li></ul><li>11 - Evite redirects<br />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;<br />Se você pode retornar a página diretamente, evite fazer o redirect, você poupa o cliente e o seu servidor do trabalho;<br />
  75. 75. 11 - Evite redirects<br />Em Java, por exemplo, você pode usar um forward() dentro de um servlet, ou incluir a página que seria redirecionada em PHP;<br />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;<br />
  76. 76. 12 – Procure e remova estilos e scripts duplicados<br />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);<br />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);<br />
  77. 77. 12 – Procure e remova estilos e scripts duplicados<br />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;<br />E também vai facilitar a vida dos desenvolvedores que vão realmente reutilizar o que já foi feito;<br />
  78. 78. 13 – Faça respostas ajax serem cacheadas<br />Mesmo em respostas a requisições AJAX você deve se preocupar com o cache de informações;<br />Sempre que possível, faça respostas AJAX serem cacheadas, assim como páginas web;<br />
  79. 79. Se você usa o Apache 2...<br />&lt;IfModulemod_deflate.c&gt;<br /> &lt;FilesMatch &quot;.(js|css)$&quot;&gt;<br />SetOutputFilter DEFLATE<br /> &lt;/FilesMatch&gt;<br />&lt;/IfModule&gt;<br />&lt;FilesMatch &quot;.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$&quot;&gt;<br /> Header set Cache-Control &quot;public&quot;<br /> Header set Expires &quot;Thu, 15 Apr 2020 20:00:00 GMT&quot;<br /> Header unsetLast-Modified<br />FileETagnone<br />&lt;/FilesMatch&gt;<br />
  80. 80. Depois do front-end...<br />Agora sim nós vamos começar a otimizar aquela query SQL que quase ninguém usa... Ou não<br />
  81. 81. Balanceie a sua carga<br />A regra é a de sempre, dividir para conquistar, divida a carga do seu servidor web em diferentes servidores de aplicação;<br />Balanceamento de carga oferece um presente de brinde, resistência a falhas (fail-over);<br />Existem ferramentas aos borbotões pra se fazer isso;<br />
  82. 82. Apache<br />Padrão de mercado, todo mundo usa, todo mundo conhece;<br />Diversos módulos com funcionalidades que você nem sabia que precisava;<br />Roda em qualquer banheira;<br />Grande demais pra resolver um problema tão pequeno;<br />
  83. 83. Nginx<br />Servidor proxy HTTP extremamente enxuto e desconhecido, vindo diretamente da terra dos Czares;<br />Leve, rápido e eficiente pra entrega de conteúdo estático e proxying;<br />Windows? Nunca será!<br />Você já tinha ouvido falar nele? Nem eu!<br />
  84. 84. Estrutura do balanceamento com um servidor de proxy<br />Tomcat 1<br />Tomcat 2<br />Tomcat 3<br />Proxy<br />
  85. 85. Vantagens do uso de proxies<br />As requisições sempre são entregues para um servidor que está “vivo”;<br />O servidor de proxy pode entregar recursos estáticos que estão nos servidores de aplicação sem nem falar com eles;<br />O servidor de proxy pode executar trabalhos custosos como compressão sem causar problemas aos servidores de aplicação;<br />
  86. 86. Bancos de dados? Mas já?<br />Crie índices para todas as colunas que forem pesquisáveis;<br />Remova índices de todas as colunas que não são realmente pesquisáveis;<br />Use o profiler do seu banco para encontrar consultas que demoram para executar;<br />Contrate um DBA;<br />
  87. 87. Admita, você já escreveu uma consulta assim<br />select * from noticias where titulo like “%tropa% %elite%”<br />
  88. 88. Likeconsideredharmful<br />Bancos de dados não são bons em buscas por texto, especialmente quando você usa os ainda mais malvados caracteres curinga ( como “%” e “*” );<br />Índices para campos de texto de muitos caracteres (TEXT ou CLOB) são um mal sem igual;<br />
  89. 89. Indexadores de texto<br />Se você realmente precisa daquele like, que você precisa é de um indexador de texto;<br />Um indexador de texto (como o Google, conhece?), é uma ferramenta especializada em organizar e buscar documentos contendo texto;<br />Ele contém otimizações específicas para buscas em texto, como ignorar palavras sem importância (preposições, pronomes, artigos...);<br />
  90. 90. Você quis dizer “banco de dados”?<br />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?);<br />
  91. 91. Luceneontheway<br />É 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;<br />Mantido pela fundação Apache, com muita documentação e livros disponíveis;<br />Está sendo utilizado como base para o indexador Hadoop do Yahoo!;<br />
  92. 92. Balanceamento de carga 2 – O Banco de dados<br />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;<br />O maior problema é fazer com que ninguém leia dados inválidos ou desatualizados;<br />
  93. 93. Um senhor de engenho, diversos escravos<br />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;<br />Você agora pode, definir vários bancos “escravos” que se atualizam baseados no banco “mestre” e recebem todas as consultas;<br />
  94. 94. Em desenho<br />Mestre<br />Escravo 1<br />Escravo 2<br />Escravo 3<br />
  95. 95. Ganhe performance e um prêmio exclusivo<br />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;<br />É uma ótima opção para criar bancos de “relatórios”, pois você roda aquelas consultas intermináveis e não mata o servidor principal;<br />
  96. 96. Problemas<br />A atualização não é instantânea, se você precisa estar atualizado 100% do tempo, isso não serve pra você;<br />Quando mais escravos, mais comunicação a rede vai ter que aguentar, então tenha um link rápido;<br />Se o master falhar, você fica impossibilitado de escrever qualquer coisa;<br />
  97. 97. Suporte?<br />Qualquer banco de dados com o mínimo de decência suporta isso;<br />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...);<br />Use o MySQL e seja feliz <br />
  98. 98. Espalhando o banco de dados em diversos bancos<br />Se o master-slave não funciona, você pode tentar sharding, que é espalhar os dados em diversos bancos de dados diferentes;<br />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;<br />
  99. 99. Sharding por características<br />Você também pode fazer sharding pelas características dos dados ( “Notícia do Brasil? manda pra aquele servidor em Mali” );<br />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;<br />
  100. 100. Problemas?<br />É o modelo mais difícil de ser implementado, passe pra isso quando você realmente não tiver mais opções;<br />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);<br />
  101. 101. O melhor é não chegar no banco de dados<br />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;<br />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;<br />
  102. 102. Caches em memória para bancos de dados<br />A sua aplicação pode evitar consultar o banco de dados usando caches em memória ou até mesmo em disco;<br />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;<br />
  103. 103. Caches em memória<br />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);<br />Existe uma infinidade de opções em todas as linguagens de programação;<br />
  104. 104. Se você está em Java...<br />...e usa o Hibernate!<br />Ele tem suporte direto a ferramentas de cache para consultas no banco de dados, tanto para caches locais como para caches distribuídos;<br />Você normalmente não precisa alterar o seu código que já funciona pra se aproveitar disso;<br />
  105. 105. Em um mundo sem Java<br />Memcached é a solução;<br />Um servidor de cache de objetos remoto, simples, fácil de usar e com bindings pra qualquer linguagem de programação;<br />Desenvolvido originalmente pelo pessoal do LiveJournal pra aguentar o tranco do site deles;<br />
  106. 106. Memcached<br />Você se conecta no servidor, manda um objeto para o cache, atribui uma chave a ele;<br />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;<br />
  107. 107. Memcached e distribuição<br />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;<br />Trate o cache como a fonte preferencial, mas lembre-se que o objeto pode não estar lá;<br />
  108. 108. Avaliando a utilização de um cache<br />Será que o cache está ajudando?<br />Quantas vezes você acerta o cache?<br />Quantas vezes o dado está lá?<br />O dado é atualizado muitas vezes?<br />Quem disse que você precisa de uma ferramenta dessas?<br />
  109. 109. Distribuição de aplicações<br />Em todos os nossos casos, a aplicação toda é movida para um novo servidor, de forma que ela possa receber a carga dos clientes;<br />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;<br />Você consegue ver um problema nisso?<br />
  110. 110. Primeira lei da distribuição das aplicações<br />Não distribua a sua aplicação<br />
  111. 111. Problemas?<br />Redes falham;<br />Máquinas falham;<br />Pessoas que pisam em fios de energia falham;<br />Cada “pequena” aplicação é o seu próprio mundo, com todos os mesmos problemas que nós falamos anteriormente;<br />
  112. 112. Mas isso não serve pra nada?<br />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;<br />Mas isso não pode ser usado como meio para se conseguir performance ou aumentar a “produtividade” de um sistema;<br />
  113. 113. Mas isso não serve pra nada?<br />Simplesmente distribuir esperando por ganhos costuma causar muito mais problemas (multiplicados por cada “mini-aplicação”) do que resolver os que você já tem;<br />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;<br />
  114. 114. fim.<br />Dúvidas? Questões? Reclamações?<br />

×