TDC2018SP | Trilha Node.js - Melhores praticas de desempenho utilizando Node.js em producao

1. Melhor Desempenho
Utilizando Node.js em produção

2. $ whoami
Software Engineer
developers@squidit.com.br
/khaosdoctor
@_staticvoid
lsantos.me
Lucas Santos

3. trainingcenter.io
help4papers.com.br
2018.abcdevelopers.org

4. Node.js production

5. Node.js production?

6. O que pode acontecer?

7. 1
Sua máquina se transforma
(Em um fogão, por exemplo)

8. 2
Você se transforma #pas

9. 3
Tudo vai bem

10. “Na minha máquina funciona” starter pack

11. Afinal o que é o Node?

13. O Node é:
Assíncrono (event Loop)
Non Blocking
Single Thread

15. Sim! Eu pesquisei

17. API’s de alta performance

18. A anatomia de uma API

19. A anatomia de uma API
Começa assim

20. A anatomia de uma API
Começa assim
Termina assim
“Ajeita ali só”

21. Maiores causas de problemas
- Muito processamento desnecessário
- Má codificação
- Conteúdo estático
- Uso indevido do Node
- Aumento de tráfego repentino

22. Maiores causas de problemas
- Muito processamento desnecessário
- Má codificação
- Conteúdo estático
- Uso indevido do Node
- Aumento de tráfego repentino (Event Loop)

23. Maiores causas de problemas
- Muito processamento desnecessário
- Má codificação
- Conteúdo estático
- Uso indevido do Node
- Aumento de tráfego repentino (C10K)

24. Por que não os dois?

25. NGINX to the rescue!
Melhorando a API através da infraestrutura

26. Cache is the key

27. Se der, cacheia, senão,
também
● Cachear arquivos estáticos
● Cachear chamadas de API
○ Por rota
○ Por hash de IP
● Cachear retornos de DB
● Cachear arquivos gerados por SSR
● Pode ser implementado via Infra (NGINX)
ou via código (Ex: Catbox-redis)

28. Proxy reverso

29. Um proxy, só que
ao contrário
Remove a carga de
conexões do node
Permite escalabilidade de
aplicações
Debounce de conexões

30. Load Balancing

31. Balanceando carga
- Escalabilidade
próxima de infinita
- Três tipos de
roteamento
- Round Robin
- Least Conn
- IP Hash

32. Simples assim
Servidores disponíveis
Load Balancer
Proxy Reverso

33. HTTP/2

34. The good, the bad
and the /1.1
Chamadas síncronas uma
a uma
O mesmo domínio só
pode responder a uma
request por vez
Bloqueio HOL (Head of
Line)

35. The good, the bad
and the /2
Multiplexing
Menos conexões
simultâneas
Mais performance
Compressão
Server push
Keep Alive

36. Simplificação

37. Simplificação

38. Show me the code

39. Código performático
Quando o problema é a peça entre a cadeira e o monitor

40. Você FAZ
diferença
- Código mais leve roda
melhor
- Tomar cuidado com
consumo de memória
- Evitar funções complexas
(principalmente loops)
- Regra das 80 colunas
- Use menos libs

41. Map vs For

42. A guerra dos loops
Loops são as funções mais custosas
que se pode ter
Adição de complexidade
Muitas vezes contornáveis

43. A guerra dos loops
Loops são as funções mais custosas que
se pode ter
Adição de complexidade
Muitas vezes contornáveis
CodeMetrics

44. Nem sempre o built-in é o melhor...
Sem filter + reduce Com filter + reduce

45. Mas, as vezes loops são melhores...

46. Hashmap vs Case

47. Voltando às
origens
- Execução paralela de todos
os caminhos possíveis
(cuidado!)
- Consome menos memória
- Menos complexidade
- Menos linhas de código
- Repetição de keywords
- Dinâmico

48. Async

49. Quando você usa funções síncronas no Node...

50. Segura aí que já
volto
- Não bloqueia o
processamento
- Impacto em tempo é
pequeno
- Otimiza o uso de recursos

51. O que vem por ai!?
- Asynchronous Iteration

52. Parallel

53. Tudo junto!
Executa múltiplas ações ao mesmo tempo
Simula um “multi-core”
Ações independentes

54. Tudo junto!
Executa múltiplas ações ao mesmo tempo
Simula um “multi-core”
Ações independentes
Evite promise-chaining
Não é paralelo!

55. Cache is the key²

56. Se der, cacheia, senão,
também²
- Cachear arquivos estáticos
- Cachear chamadas de API
- Por rota
- Por hash
- Cachear retornos de DB
- Cachear arquivos gerados por SSR
- Pode ser implementado via Infra (NGINX) ou via
código (Ex: Catbox-redis)

57. SSR?

58. Será que vale?
Processamento muito intenso do
lado do servidor
Bom para páginas pequenas
Distribua o processamento no
cliente
É uma boa prática dependendo
do caso

59. Node Cluster API
Porque sim! Node pode ser multi-core

60. Clusters
- Utilizam o processamento
multi núcleo
- Nativo do Node!
- Simples e fácil

61. Clusters
- Utilizam o processamento
multi núcleo
- Nativo do Node!
- Simples e fácil
- Estável
https://nodejs.org/api/cluster.html

62. Use mais o V8!

63. Use mais o V8!
Não use Lodash
Não use Lodash
Não use Lodash
Não
use
Lodash
NãouseLodash
NãouseLodash
Não use Underscore
Não use Underscore
Não
use
Underscore
Não
use
Underscore
Não use jQuery
Não
use
jQuery
NãousejQuery
NãouseUnderscore
Não
use
jQuery

64. Use mais o V8!
Não use LoDash(e derivados)

65. POR… QUE?
- Libs são úteis em casos
específicos, use nesses
casos…
- Pensadas para o
browser (muito código
inútil)

66. Agora sim
- Quando a lógica é
complexa
- ...ou não intuitiva
- Tipo:

67. Outros pontos

68. Outras coisinhas
- Gerenciamento de
sessões ocupa
memória
- Utilize projeção no
banco de dados
- Use plataformas de
monitoramento

69. Workers/Jobs de alta performance

70. O que é um e o que é outro?
Worker
- Sempre ativo na máquina
- Roda por eventos disparados de
fora
- Consome mais memória (fica
ligado direto)
- Mais propenso a memory leak
Job
- Fica inativo
- Roda apenas em horários ou
intervalos determinados
(CronJob)
- Consome memória em picos

71. Coletando o lixo

72. Yes, we have GC
- Node tem um garbage
collector
- Funciona após 1.4Gb de
memória ocupada (Heap
Limit do V8)
- Dividido em Old Space e
New Space (???)
https://blog.risingstack.com/finding-a-memory-leak-in-node-js/

73. Garbage Collection in depth
Deletamos um obj. GC Roda
Perdeu Root = Memória não usada
New Space Old Space

74. Garbage Collection in depth
Deletamos um obj. GC Roda
Perdeu Root = Memória não usada
New Space Old Space
MUITO CUIDADO

75. Coletando o lixo (Manualmente)

76. Profiling
- Utilização de libs de
profiling
- Usar profiler nativo do
node:

77. FlameGraph

78. Node.js production!

79. Perguntas?

80. Obrigado!
/khaosdoctor @_staticvoidlsantos.me