TDC2018SP | Trilha Node.js - Melhores praticas de desempenho utilizando Node.js em producao
•
0 gostou•191 visualizações
O documento discute técnicas para melhorar o desempenho de aplicações Node.js em produção, incluindo cache de arquivos estáticos e respostas de API, uso de proxy reverso e balanceamento de carga para escalabilidade, e otimizações de código como evitar loops desnecessários.
Mais conteúdo relacionado
Mais procurados
Mais procurados (16)
Semelhante a TDC2018SP | Trilha Node.js - Melhores praticas de desempenho utilizando Node.js em producao
Semelhante a TDC2018SP | Trilha Node.js - Melhores praticas de desempenho utilizando Node.js em producao (20)
Mais de tdc-globalcode
Mais de tdc-globalcode (20)
Último
Último (20)
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
- 6. O que pode acontecer?
- 7. 1 Sua máquina se transforma (Em um fogão, por exemplo)
- 8. 2 Você se transforma #pas
- 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
- 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
- 79. Perguntas?