Atendendo Milhares de Requisições com o Play Framework 2 - v2

1,064 views

Published on

Com testes de carga, esta palestra mostra como a Lojinha (lojinha.jcranky.com e github.com/jcranky/lojinha) pode atender a milhares de requisições, sem complicações. A primeira versão desta palestra foi apresentada no Just Java 2013, e a segunda (atual) no TDC 2013 em SP.

Published in: Technology
2 Comments
0 Likes
Statistics
Notes
  • Obrigado =)

    Não tem balanceamento de carga porque usei apenas um servidor para o Play, e um para o PostgreSQL. Fazer um cluster e trabalhar o balanceamento de carga são planos para o futuro.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Caraca, massa! Você tentou fazer balanceamento de carga aí? Mas ficou muito legal mesmo, parabéns!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
1,064
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

Atendendo Milhares de Requisições com o Play Framework 2 - v2

  1. 1. Atendendo Milhares de Requisições com o Play Framework 2 Paulo “JCranky” Siqueira jcranky.com / @jcranky youtube.com/jcrankydev
  2. 2. Agenda ● A aplicação e os cenários ● Os testes – números e alguns porquês ● Conceitos e decisões importantes
  3. 3. A aplicação: Lojinha
  4. 4. Onde está a Lojinha? ● Em produção: http://lojinha.jcranky.com/ ● Código-fonte (open-source): https://github.com/jcranky/lojinha/
  5. 5. Tecnologias
  6. 6. Cenário 1 ● 150 usuários ● Acesso ao Feed xml dos items ● Executado 40 vezes – 6000 requisições no total
  7. 7. Cenário 2 ● 120 usuários ● Acessando a página inicial ● Executado 400 vezes – 48000 requisições no total
  8. 8. Cenário 3 ● 60 usuários ● Acessando a página de um Item ● Executado 400 vezes – 24000 requisições no total
  9. 9. Cenário 4 ● 15 usuários ● Fazendo um lance em um Item ● Executado 400 vezes – 6000 requisições no total
  10. 10. Resumo ● 84000 requisições variadas ● Diversos GETs ● Um POST (oferta em um item)
  11. 11. Ferramental para os Testes ● Apache JMeter ● Amazon EC2 <3 <3 <3 <3
  12. 12. Plano de Testes Arquivo .jmx disponível no github da Lojinha
  13. 13. Teste #1 ● Play e JMeter na máquina local ● Banco de dados H2 (em memória) ● Apenas dois produtos cadastrados
  14. 14. Teste #1 ● Longe do cenário real / ideal... ● ...mas ajuda a estabilizar o sistema – Bugs foram encontrados nessa fase
  15. 15. Teste #1 ● Resultado: +/- 180 Requisições por segundo ou 10 mil por minuto
  16. 16. Teste #1 - análise ● BD em memória e embutido no Play elimina muito overhead ● Pode esconder problemas no acesso aos dados
  17. 17. Teste #2 ● Igual ao anterior... ● ...mas agora usando o cache do Play: – Página inicial – Página dos items
  18. 18. Teste #2 – código original def index = Action { // corpo simplificado Ok(html.index()) }
  19. 19. Teste #2 – código com cache // index cacheado por 5 segundos def index = Cached("index", 5){ Action { // corpo simplificado Ok(html.index()) } }
  20. 20. Teste #2 ● Resultado: +/- 800 Requisições por segundo ou 48 mil por minuto
  21. 21. Teste #2 – análise ● A grande maioria dos acessos foi lida do cache ● Acessos sem cache também melhoram – o hardware não está sobrecarregado
  22. 22. Teste #3 ● Agora é para valer! ● Três servidores: – JMeter – PostgreSQL – Play Framework 2.0
  23. 23. Teste #3
  24. 24. Teste #3 ● Instâncias AWS: – JMeter: micro – Play: medium – PostgreSQL: medium-highcpu
  25. 25. Teste #3 ● Sem cache ● Dados reais – Clonados da Lojinha em produção – 82 produtos
  26. 26. Teste #3 ● Resultado: +/- 5 Requisições por segundo ou 300 por minuto
  27. 27. Teste #3 - análise ● CPU do PostgreSQL “no talo” ● CPU do Play entre 50 ~ 60 % ● Tunning no pool de conexões ajudou um pouco
  28. 28. Teste #4 ● Mesmos três servidores ● Agora com cache ● BD “resetado”
  29. 29. Teste #4 ● Resultado: ~294 Requisições por segundo ou mais de 17 mil por minuto
  30. 30. Teste #4 - análise ● CPU do PostgreSQL ainda “no talo” ● CPU do Play acima de 90% ● Menos acesso ao BD, mais tempo respondendo requisições
  31. 31. Em tempo ● Não analisei uso de memória ou CPU ● Apenas observei, sem coletar dados ● Uso de memória pareceu muito baixo
  32. 32. Outras implantações ● PostgreSQL e Play na mesmo instância ficou inaceitável ● Instância micro para o Play e PostgreSQL também não
  33. 33. Princípios seguidos ● Desenvolvimento da Lojinha sempre foi despreocupado com performance ● Mas seguindo princípios importantes – Alguns “empurrados” pelos frameworks
  34. 34. Princípios seguidos ● Uso de cache ● Obviamente, indispensável para atender muitas requisições – Feed, Página de Item, Página Inicial
  35. 35. Princípios seguidos ● Imagens no Amazon S3 ● Download de imagens tem impacto zero na Lojinha
  36. 36. Princípios seguidos ● Imutabilidade ● Result é imutável – Portanto, seguro de cachear
  37. 37. Princípios seguidos ● Assincronia – Processamento dos lances – Envio de e-mails (lances recebidos) – Akka #ftw
  38. 38. Processamento dos lances ● Controller bloqueia ● Processamento interno não – Ofertas em items diferentes são processados em paralelo
  39. 39. Processamento dos lances ● Possível melhoria: – Não bloquear o Controller – Async do Play – Testarei no futuro para verificar se há melhorias de performance
  40. 40. Exemplo: envio de e-mail EMail.actor ! BidReceivedMessage( bidProcessor.item.name, itemUrl, email)
  41. 41. Princípios seguidos ● Sem sessão no lado do servidor ● Característica do Play ● Evita consumo excessivo de memória ● Facilita clustering
  42. 42. Demo rodando os testes localmente
  43. 43. Melhorias ● Página inicial maior do que necessário ● Possível solução: barra de rolagem infinita
  44. 44. O que vêm por aí! ● Pequena série de videos, mostrando os testes passo a passo ● Assinem o canal para acompanhar: youtube.com/jcrankydev
  45. 45. Perguntas?
  46. 46. Obrigado! Paulo “JCranky” Siqueira @jcranky / jcranky.com youtube.com/jcrankydev

×