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.

1. Atendendo Milhares de Requisições
com o Play Framework 2
Paulo “JCranky” Siqueira
jcranky.com / @jcranky
youtube.com/jcrankydev

2. Agenda
●
A aplicação e os cenários
●
Os testes
– números e alguns porquês
●
Conceitos e decisões importantes

3. A aplicação: Lojinha

4. Onde está a Lojinha?
●
Em produção:
http://lojinha.jcranky.com/
●
Código-fonte (open-source):
https://github.com/jcranky/lojinha/

5. Tecnologias

6. Cenário 1
●
150 usuários
●
Acesso ao Feed xml dos items
●
Executado 40 vezes
– 6000 requisições no total

7. Cenário 2
●
120 usuários
●
Acessando a página inicial
●
Executado 400 vezes
– 48000 requisições no total

8. Cenário 3
●
60 usuários
●
Acessando a página de um Item
●
Executado 400 vezes
– 24000 requisições no total

9. Cenário 4
●
15 usuários
●
Fazendo um lance em um Item
●
Executado 400 vezes
– 6000 requisições no total

10. Resumo
●
84000 requisições variadas
●
Diversos GETs
●
Um POST (oferta em um item)

12. Ferramental para os Testes
●
Apache JMeter
●
Amazon EC2
<3 <3 <3 <3

13. Plano de Testes
Arquivo .jmx
disponível no
github da Lojinha

14. Teste #1
●
Play e JMeter na máquina local
●
Banco de dados H2 (em memória)
●
Apenas dois produtos cadastrados

15. Teste #1
●
Longe do cenário real / ideal...
●
...mas ajuda a estabilizar o sistema
– Bugs foram encontrados nessa fase

16. Teste #1
●
Resultado:
+/- 180 Requisições
por segundo
ou 10 mil por minuto

17. Teste #1 - análise
●
BD em memória e embutido no Play
elimina muito overhead
●
Pode esconder problemas no acesso
aos dados

18. Teste #2
●
Igual ao anterior...
●
...mas agora usando o cache do Play:
– Página inicial
– Página dos items

19. Teste #2 – código original
def index = Action {
// corpo simplificado
Ok(html.index())
}

20. Teste #2 – código com cache
// index cacheado por 5 segundos
def index = Cached("index", 5){
Action {
// corpo simplificado
Ok(html.index())
}
}

21. Teste #2
●
Resultado:
+/- 800 Requisições
por segundo
ou 48 mil por minuto

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

23. Teste #3
●
Agora é para valer!
●
Três servidores:
– JMeter
– PostgreSQL
– Play Framework 2.0

24. Teste #3

25. Teste #3
●
Instâncias AWS:
– JMeter: micro
– Play: medium
– PostgreSQL: medium-highcpu

26. Teste #3
●
Sem cache
●
Dados reais
– Clonados da Lojinha em produção
– 82 produtos

27. Teste #3
●
Resultado:
+/- 5 Requisições por segundo
ou 300 por minuto

29. Teste #3 - análise
●
CPU do PostgreSQL “no talo”
●
CPU do Play entre 50 ~ 60 %
●
Tunning no pool de conexões ajudou
um pouco

30. Teste #4
●
Mesmos três servidores
●
Agora com cache
●
BD “resetado”

31. Teste #4
●
Resultado:
~294 Requisições por segundo
ou mais de 17 mil por minuto

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

34. Em tempo
●
Não analisei uso de memória ou CPU
●
Apenas observei, sem coletar dados
●
Uso de memória pareceu muito baixo

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

36. Princípios seguidos
●
Desenvolvimento da Lojinha sempre foi
despreocupado com performance
●
Mas seguindo princípios importantes
– Alguns “empurrados” pelos frameworks

37. Princípios seguidos
●
Uso de cache
●
Obviamente, indispensável para
atender muitas requisições
– Feed, Página de Item, Página Inicial

38. Princípios seguidos
●
Imagens no Amazon S3
●
Download de imagens tem impacto zero
na Lojinha

39. Princípios seguidos
●
Imutabilidade
● Result é imutável
– Portanto, seguro de cachear

40. Princípios seguidos
●
Assincronia
– Processamento dos lances
– Envio de e-mails (lances recebidos)
– Akka #ftw

41. Processamento dos lances
●
Controller bloqueia
●
Processamento interno não
– Ofertas em items diferentes são
processados em paralelo

42. Processamento dos lances
●
Possível melhoria:
– Não bloquear o Controller
– Async do Play
– Testarei no futuro para verificar se há
melhorias de performance

43. Exemplo: envio de e-mail
EMail.actor ! BidReceivedMessage(
bidProcessor.item.name, itemUrl, email)

44. Princípios seguidos
●
Sem sessão no lado do servidor
●
Característica do Play
●
Evita consumo excessivo de memória
●
Facilita clustering

45. Demo
rodando os testes localmente

46. Melhorias
●
Página inicial maior do que necessário
●
Possível solução: barra de rolagem
infinita

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

48. Perguntas?

49. Obrigado!
Paulo “JCranky” Siqueira
@jcranky / jcranky.com
youtube.com/jcrankydev