Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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
Upcoming SlideShare
Loading in …5
×

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

1,191 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
  • 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

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

×