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

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

1.041 visualizações

Publicada em

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.

Publicada em: Tecnologia
2 comentários
0 gostaram
Estatísticas
Notas
  • 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.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Caraca, massa! Você tentou fazer balanceamento de carga aí? Mas ficou muito legal mesmo, parabéns!
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.041
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
0
Comentários
2
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no 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

×