Tornando sua App Web Mais Rápida! | 4 Técnicas de Otimização

Olá pessoal Fábio Akita hoje vai ser um tema bem complicado de acompanhar mas é para vocês programadores iniciantes fazendo curso superficiais ou aprendendo a fazer suas primeiras aplicações web o objetivo é tentar explicar Qual a diferença do seu app que acabou de conseguir fazer subir na sua máquina depois de ver alguns tutoriais e o que se faz em aplicações de empresas de verdade como Amazon Mercado Livre da vida porque o e-commerce que você fez passo a passo assistindo um vídeo no YouTube não se parece com nada com uma aplicação de verdade qual a diferença vamos

entender o que eu vou mostrar Hoje existe detalhado em diversos tutoriais blog post documentação para cada Framework web eu poderia mostrar exatamente qual o jeito que se faz em Rubem raios ou springbuth mas eu quero que o foco não seja a linguagem ou Framework mas sim os conceitos em outro Episódio talvez eu explore um pouco mais no nível do código mas para hoje os conceitos são mais importantes do que o código em si que você pode achar facilmente no Google tudo que eu disser aqui é válido para qualquer Framework web não existe nada que uma

linguagem ou Framework que faça que a outra também não faça muita gente pensa que o segredo é escolher a linguagem certa mas não é saber como as coisas funcionam além do passo a passo vamos recapitular rapidinho você abre seu navegador e chama elas um ponto com.br um navegador em pacote esse pedido no que chamamos de um http Quest uma estrutura de dados que segue o protocolo http Esse pacote sai da sua máquina via rede cai na internet como eu expliquei nos Episódios sobre rede e chega até um dos servidores da Amazon seja Do que é

feito a aplicação deles Possivelmente Java recebe essa requisição ele monta a página html empacota no htdp o expulso de resposta e devolve pela mesma conexão de volta para o seu navegador que finalmente renderiza a homepage deles para você ver se abriu o de velopertuss e ir na aba de rede dá para ver exatamente o cabeçalho do pacote de requisição aqui olha só o endereço que pedimos e outros detalhes como que navegador tá usando e em seguida temos o pacote de resposta que contém um cabeçalho com o código de resposta 200 que significa que deu tudo

certo e no corpo vem o HTML se tiver estudando front-endi ou mesmo se baixar um template pré Pronto acho que todo estudante assistindo aqui consegue imaginar fazendo essa página em laravel Express Spring jungles basta ter um banco de dados qualquer seja em mais rico ou post ou mongo montar o HTML e devolver um pseu do código seria mais ou menos assim um template HTML e uma lógica que faz select na tabela de pega os 20 ou 10 primeiros e monta a lista de produtos em HTML qualquer um que tenha assistido qualquer curso online sabe fazer

até aqui certo se for uma aplicação em inglês você sobe ela com o comando server se for Django sobe com python Manager se for Express pode subir com npm Run deve ou seja lá como chamou a taski se for laravel vai subir com PHP artesão serve se foi Spring vai subir com bredal boot Run se foi elix vai subir com Mix ponto server todo framer que tem uma forma de iniciar o servidor web que vai servir a aplicação se funciona assim na sua máquina provavelmente já imaginou que bastaria então criar um servidor remoto na digital

oxa lenode aws é azul instalar linguagem clonar o código fonte do seu projeto e executar o mesmo comando nos servidor e pronto tá terminado né você já é um programador web fácil basta agora registrar um domínio apontar para esse servidor e pronto seu site está no ar e sim esse é o jeito errado de fazer agora que a coisa começa já notou que quando sobe uma aplicação web na sua máquina O framer que costuma abrir uma porta como 3.000 ou 4.80 tudo menos porta 80 mas eu acho que até o mais iniciante ou se assistiu

meus vídeos de rede sabe que o navegador por padrão manda requisições na porta 80 ou 443 do servidores Então por que o frame que eu já não deixa sua aplicação rodando na porta 80 direto dois motivos primeiro porque para subir na porta é 80 precisa ter privilégios de administrador daí você seria obrigado a subir usando o comando súbu toda hora o que não é recomendado mas em segundo lugar porque nenhum Framework web foi feito para rodar diretamente exposto na internet na porta 80 por exemplo tirando Java que são iguais com suporte atrás e multi tread

todas as linguagens de script java script pega HP Python e Ruby são feitos para rodar primariamente numa trade só Sim eles têm um certo suporte a Multi trads mas via de regra a soma que o processo que sobe tem capacidade de saturar somente um dos núcleos da CPU da sua máquina ou do servidor pode fazer o teste faça um código que fica sei lá fazendo um Loop Infinito fazendo qualquer coisa e roda agora abra o monitorador de CPU com uma H top e vai ver que sua máquina tem várias cpus mas a maioria delas não

tá sendo usada se for instalar no servidor digamos de quatro núcleos o certo é subir sua aplicação web 4 vezes um processo por núcleo Talvez um pouco menos depende da carga eu já falo disso mas só um processo vai desperdiçar sua CPU um dos processos pode subir na porta 3.000 o segundo na porta 3001 a outra 3002 e assim por diante cada processo precisa dar banho de uma porta diferente mas aí fodeu Como que o navegador do usuário vai saber com que porta conectar Você nunca teve que digitar a amazon.com.br dois pontos 3002 por exemplo

Como eu disse nenhum Framework web foi feito para ser exposto direto na internet processos web sempre ficam atrás de um balanceador de carga um outro programa como proxy ou o mais comum de hoje em dia em de Next eles fazem um processo chamado proxy reverso quem fica exposto na porta 80 ou 443 é um end next os usuários mandam requisições para esse balanceador de carga que por sua vez sabe que tem quatro processos nas portas 3000 a 3003 de pé no servidor por trás e fazem round Robin ou alguma outra estratégia de balanceamento para mandar

uma requisição para cada processo Tentando Manter todos igualmente ocupados o usuário final não sabe que na primeira vez caiu no processo na porta 3002 quando clicou no link pedido da outra página caiu na porta 3003 e assim por diante para ele é transparente porque só enxerga o balanceador de cargas e o processo atrás também não sabe que existe um balanceador na frente ele recebe a requisição http como se o usuário tivesse conectado direto nele como se faz na sua máquina local de desenvolvimento quando você pede o local roxo dois pontos 3.000 no navegador mas esse

é o primeiro jeito mais simples do que chamamos de escalabilidade faz de conta que a lógica que você fez no seu código para puxar produtos do banco de dados montar o HTML tudo mais leve em média 100 milissegundos significa que esse um processo que você subiu na porta 3000 tem capacidade de responder até 10 requisições por segundo já que um segundo tem milissegundos se vier mais do que 10 requisições no mesmo segundo os que vieram depois ficam numa fila esperando o processo desocupar por isso Subimos mais de um processo na mesma máquina se subirmos 4

processos no servidor a grosso modo passamos a suportar 40 requisições por segundo é isso que chamamos de Foot do Servidor que é a capacidade de quantas requisições ela consegue responder por segundo nenhum programador iniciante pensa muito nisso mas o código que você faz Tem um limite de quanto consegue responder por período de tempo não é mágica quanto mais gente for usar sua aplicação ou Subimos mais processos nem mais servidores ou damos um jeito de fazer requisição sem responder mais rápido para ter mais capacidade no mesmo processo por isso que a gente tira tanto sarro de

programador copy peixe destaque overflow porque vocês que fazem isso as cegas estão adicionando o código que diminui a capacidade de resposta de cada processo um proxy reverso como o indinext serve como primeira barreira de segurança ele é um software mais simples melhor otimizado mais seguro e que muda muito menos que o servidor web que vem com o seu Framework seja o Tomcat de Java ou com uma de rubi ou o Cowboy de elixir é boa prática esconder eles atrás do end next mas não só isso além de servir para Balancear a carne de requisições entre

vários processos é nele que também instalamos coisas como certificado SSL para abrir conexões seguras via https o navegador fecha uma conexão encriptada com o end next mas atrás dele x manda http não criptografado para sua aplicação dessa forma sua aplicação não precisa se preocupar em lidar com coisas como certificados o que Facil muito mais o gerenciamento de infraestrutura para os devopes sem entrar em detalhes no mundo coobernets Esse é o papel do controlador inglês que pode usar o end next como proxy reverso também em resumo uma aplicação de verdade vai ter end next balanceando carga

para múltiplos processos da sua aplicação web Possivelmente em múltiplos servidores só que mesmo também não escala infinitamente E se o meu balanceador de carga tiver no limite tem vários jeitos de resolver isso e um deles é direto no DNS quem assistiu meus vídeos de rede vai lembrar que quando pedimos para o DNS resolver um domínio o DNS devolve um endereço IP Esse é o endereço IP para o servidor que tem o end next ou equivalente mas no caso de serviços muito grandes como Google Amazon eles devolvem múltiplos e endereços IPS e essa é a razão

porque tem vários servidores de balanceamento de carga Inclusive tem um conjunto de servidores específicos para cada região geográfica se pedirmos a amazon.com do Brasil vai voltar um conjunto de endereços para servido daqui mas se tiver no Japão vai receber um conjunto de endereços diferentes para servidores da Ásia é assim que uma Amazon da vida consegue escalar em nível Mundial lógico para a maioria de nós um único servidor de Andy next costuma ser mais que suficiente mas é bom saber que essas técnicas existem e aí você pensa beleza entendi Se eu fizer uma home page que

responde em 100 milissegundos e eu subi quatro processos num drop de digital oxa significa que eu consigo responder até 40 requisições por segundo se eu vendo Analytics que minha campanha de marketing deu certo e o tráfico da subindo para 80 requisições por segundo Das duas uma ou eu faço upgrade na máquina para ter oito núcleos para subir o dobro de processos ou eu subo um segundo servidor pra subir quatro processos novos reconfigura o indinex pra saber que existem esses quatro novos processos e ele passa a Balancear a carga para lá também quando fazemos upgrade da

mesma máquina chamamos de escalabilidade vertical quando colocamos novas máquinas embaixo do balançador de carga chamamos de escalabilidade horizontal e falando desse jeito parece simples se o tráfico aumentar para 400 requisições por segundo é só subir 10 servidores embaixo do end next certo só que não quem dera fosse fácil assim o que eu vou falar agora tem muitas nuances por causa do comportamento de múltiplas trads mas eu vou tentar simplificar para ficar fácil de visualizar só entenda que é mais complicado do que isso lembra do vídeo do herocco eu ainda recomendo como melhor lugar para iniciar

mesmo tendo cancelados os planos gratuitos para só brincar precisa achar outro lugar mas se pretende colocar um microsc no ar e queria colocar num plano gratuito você precisa repensar seu negócio uma aplicação que sequer consegue pagar a própria infraestrutura tem problemas muito mais sérios do que custo de máquina uma das vantagens é que essa parte toda de balanceador de carga e de Next é transparente eles gerenciam você só precisa mandar subir os processos nos servidores deles que eles chamam de danos e o balanceador é automaticamente reconfigurado tem uma calculadora online que vai nos ajudar a

ilustrar o que eu quero dizer aqui olha só Digamos que estamos naquele cenário de 400 requisições por segundo não dá no pequeno de quatro cordas a recomendação é subir três processos se pegar um Dino maior o recomendado é subir o total de Corsa -1 lembra que o sistema operacional também precisa de um pouco de CPU para gerenciar o que roda por cima e por isso não queremos saturar tudo só com o nosso aplicação você tem que saber pensar essas coisas então vamos subir três processos só que aí para responder 400 requisições por segundo 10 requisições

por processo dividido por três processos vão precisar de pelo menos 13 dinos eu disse que linguagens discripts lidam com múltiplas trades diferente de Java Ou elix eles têm threads só não consegue rodar todas em paralelo o tempo todo eu falo sobre isso no episódio sobre concorrência e paralelismo mas na prática podemos configurar cada processo para aceitar digamos cinco tracks ou seja cinco conexões simultâneas não pense muito sobre isso agora mas o importante é o a seguir cinco conexões a banco de dados no pulde conexões e o que diabos é um pulo de conexões conexão a

banco de dados é uma operação que custa recursos do banco de dados não dá para ficar abrindo conexão infinitamente estou notando um tema no vídeo de hoje nada é infinito em programação você como iniciante só não sabe disso porque só testando seu programinha do tutorial sozinho é muito pouco para chegar no limite mas na internet com milhares de usuários de verdade usando toda hora vai esbarrar em limites e sua função como programador é saber como gerenciar esses limites pensa assim Cada sessão de uma conexão no banco de dados precisa ser registrado em algum lugar esse

registro vai gastar memória e CPU quanto mais conexões mais memória e CPU vai se gastar para gerenciar todo mundo seja o processo da sua aplicação web ou processo do banco de dados sem o limite uma de duas coisas vai acontecer ou vai acabar memória ou vai acabar processamento mas um dos dois vai acabar quando isso acontecer tudo trava para de responder e não queremos que isso aconteça então configuramos limites para conseguirmos pelo menos ter processamento para rejeitar e devolver erro caso um dos limites seja atingido antigamente a gente deixava rodando até passado limite e era

o caso onde páginas na web ficava com ampulheta de carregando por minutos sem resposta hoje tomamos um time malte pelo menos uma das técnicas que adotamos lá na virada do século foi pude conexões Digamos que minha aplicação Java mal feita saísse abrindo conexões esquecendo de fechar elas rapidamente o limite do banco ia estourar se o mesmo banco fosse usado por várias aplicações diferentes Bastava uma mal feita para saturar todas as conexões em vez disso limitamos a quantidade que cada aplicação pode usar a aplicação deixa de conectar direto no banco em vez disso ela se conecta

num pum e esse Puma tem um certo número fixo de conexões abertas com o banco um exemplo da calculadora cada processo da sua aplicação pode ser configurado com cinco conexões se tiver processos no mesmo daino cada Dino vai consumir 15 conexões com o banco se o banco suportar até 150 conexões dá para subir até 10 dias em teoria e isso deveria ser suficiente se cada processo aceita até cinco treads mutantes e cada tread precisa de uma conexão vai ter pelo menos um para cada quando o Atlético terminar de usar conexão ela devolve para o pum

para poder ser reusada por outra trade o Pou faz meio que o papel do Andy next entra o navegador do usuário e sua aplicação é um intermediário de balanceamento no caso a função do público de conexões É permitir múltiplas dreads da aplicação em usar conexões já existentes em vez de toda hora tentar abrir novas conexões E com isso conseguimos controlar a quantidade máxima de conexões sendo utilizadas ao mesmo tempo serviços como heroico post ou a wsrds tem diversos planos de tamanhos e preços diferentes um iniciante Pensa num plano de banco de dados mais como dólares

por capacidade de armazenamento de dados sei lá $10 para um tb 100 dólares para 10 tb ou algo assim mas mais importante que total de armazenamento é qual o máximo de conexões que cada plano oferece um plano básico de heroccupoachings pode oferecer digamos 120 conexões no máximo ou seja de acordo com a simulação que fizemos na calculadora subindo minha aplicação em 13 dinos com cinco treas cinco conexões 3 x 5 x 5 significa que preciso de no mínimo 195 conexões para o banco de dados ou seja um plano básico de 120 conexões máximas já não

vai dar se realmente tiver as Tais 400 requisições por segundo Das duas uma ou eu pago mais e aumento o meu plano de post ou eu coloco um paliativo que é um gerenciador de conexões Como pedir Bowser na frente do postres a grosso modo funciona assim antes na sua máquina sua aplicação conectava direto no banco de dados não fazemos mais isso todo Framework decente já traz um pulo de opções para você usar e é ele quem se conecta no banco mas podemos colocar uma camada a mais e o Pou também não fala mais direto com

o banco e sim com outro intermediário o pi de balsa o pi de balsa vai usar no máximo 75% do máximo de conexões do banco nesse caso seria umas 90 conexões Mas ele tem capacidade de deixar até 10 mil pedidos de conexão pendurados em cima dele antes de dar erro significa que não vamos tomar erro de falta de conexão mas a requisições precisam esperar mais tempo e se ficar pesado demais tomar time Malte de qualquer jeito só estamos tentando esticar um pouco mais é como se fosse a fila de um Poupatempo ou cartório da vida

só tem 90 tendentes mas tem 195 pessoas na fila as primeiras noventas são atendidas imediatamente o pidgeball são as cadeiras de espera para as outras 105 ficar esperando com a senha para serem atendidos a solução de todos os limites em programação é a mesma de uma repartição pública fazer fila e esperar a vez só que isso é um paliativo significa disse antes cada requisição era respondida em até uns 100 milissegundos agora pode levar mais tempo talvez 120 milissegundos Isso muda a conta toda que fizemos até agora se o número de processos por Dino é fixo

precisamos subir mais dinos mais se subirmos mais designs carregamos mais processos isso vai pressionar mais o público de conexões que vai exigir mais conexões ao banco de dados estão entendendo como as coisas não são fáceis Existem várias formas de resolver isso chegamos ao limite do que só configurando em infraestrutura pode fazer será que não dá para resolver isso no código Opa Talvez sim dos 100 milissegundos que sua aplicação web leva para montar home page 50 é Gasta só mandando a Kelly de select pro banco recebendo as linhas de resposta e processando esses dados Mas pensa

comigo no seu e-commerce pequeno literalmente todo mundo que pedir a home page vai acabar vendo os mesmos produtos não vai se vieram 400 requisições de home page você fez 400 pesquisas do banco de dados que fica respondendo 400 vezes alguma coisa isso é um desperdício todo Framework web que se preza já tem embutido recurso para fazer cachen Cash é guardar a última resposta para não reprocessar tudo de novo a mesma coisa se fizermos a implementação mais simples de tosca fazemos um código para o seguinte procure por um arquivo local chamado Cash home page se não

tiver faça a mesma coisa de antes solicite uma conexão ao banco para o pum mande o select para fazer a pesquisa Receba as linhas resposta processo e Monte HTML baseado nos produtos recebidos mas agora antes de devolver para o usuário grave um arquivo local chamado Cash home page pronto na próxima requisição por home page que vier agora vai encontrar esse arquivo podemos checar que esse arquivo não é mais velho que cinco minutos faz de conta e pulamos toda a parte de falar com o banco de dados devolvendo direto que tiver nesse Cash entendeu Vamos fazer

as contas Digamos que Subimos só 8 dias com três processos cada cinco trads e cinco conexões do pum o que vai todas a 120 conexões que o banco postics que eu contratei suporta no máximo desse plano daí começa a vir requisições Digamos que o ind Max balançou perfeitamente as primeiras oito requisições que chegaram mando um para cada um dos oito dinos em cada Dino o processo que respondeu primeiro fez conexão com o banco de dados e deixa esse arquivo Cash home page para trás agora chegou o resto das 392 requisições durante um segundo Sabe quantas

conexões para o banco foram abertas nesse segundo antes precisava de 195 agora precisou de zero sacaro zero Porque toda a requisição que veio depois que o arquivo de Cash foi gravado leu direto desse arquivo e não precisou conectar nem no pum nem no banco e se arbitrariamente estabelecemos escalista de produtos não corre risco de sofrer alterações durante 5 minutos por 5 minutos essa homepage passa a consumir zero conexões com o banco de dados Esse é o tipo de otimização simples com alto impacto antes precisávamos de 195 conexões o banco por segundo agora precisamos de não

mais que uns 10 a cada 5 minutos e como 50 milissegundos por requisição era gastos só nesse trabalho com o banco significa que na média eu diminui o tempo de cada requisição pela metade sem trocar linguagem sem trocar Framework sem reescrever aplicação eu poderia diminuir pela metade a quantidade de danos para responder as mesmas 400 requisições por segundo ou eu deixo Como tá E posso fazer mais marketing para dobrar o tráfego e ainda consigo responder todo mundo com folga eu vou insistir no conceito para martelar na cabeça de vocês trocar de linguagem ou frame que

sair de pai etern para java script eu saí de dot net para Java sair de Lara véu e pré-express ou qualquer coisa assim pode dar alguma diferença pequena em algumas partes 5%, 10%, mas técnicas como essa de Casting colocadas em lugares inteligentes de autotráfico podem economizar recursos em ordem de grandeza cinco vezes 10 vezes ou até mais é esse tipo de otimização que vale a pena fazer gastar semanas para ter ganho de 1% 2% não vale a pena gastar horas para ganhar cinco vezes 10 vezes isso sim vale a pena eu falei arquivo só para

explicar o conceito mais fácil mas na realidade não usamos arquivos para cache usamos um segundo banco de dados mais leve como mancache ou redis são bancos que não tem as garantias de um post de atomicidade consistência integridade ou durabilidade Ou seja pode ser que eu mande gravar ele não grave um registro Pode ser que grave mas quando for ler não tá lá ainda pode ser que grave duas vezes se fosse um banco de dados de pagamento isso seria um problema mas para cash não não tem problema porque a lógica da aplicação que fizemos é se

existir no cash e não expirou usa se não existir conecta no banco remoto HTML e grava um novo cash não ter essas garantias significa que uma enquete ou redis consegue executar muito mais rápido e aceitam uma ordem de grandeza mais conexões simultâneas por isso configuramos um maincache que é um serviço barato e fazemos essa lógica de Cache para ler e gravado uma enquete em vez de um arquivo a desvantagem que precisamos pagar mais um serviço mas ele é barato e economiza mais ainda os recursos do banco porque antes cada dia precisava gerar seu próprio arquivo

de Cash então quanto mais dai-nos mais continua precisando puxar do banco da primeira vez agora só precisa de uma vez e todos os danos lendo o mesmo cache Como o próprio nome diz é Memory Cash é literalmente um Cash em memória por isso que quando o servidor de mancash reinicia perde tudo que tinha armazenado Mas não tem problema porque toda a aplicação que depende do Cash sabe como reaquecer esse cash ou seja reconstruir os dados que precisa em cash para a próxima requisição é parecido mas com a vantagem que também grava em disco daí se

reiniciar ele sabe reaquecer sozinho ele é um pouca coisa mais lento mas tem durabilidade de novo é um traidor Em ambos os casos significa que não precisamos aumentar o plano do de dados relacionados mas a coisa não termina aqui isso foi só hello world do Hello Word bancos de dados é outro assunto infinito que daria para fazer um canal inteiro só sobre esse assunto mas o importante é que todo banco de dados tem perfis de performance de escrita e de leitura um banco de dados relacional com o mais ciclo posts se conserva orako costuma ter

perfis de leitura rápida mas escrita lenta justamente porque tem as características como garantia esse de que eu falei antes é lento para escrever porque se ele diz que escreveu é porque escreveu escreveu garantidamente correto ninguém vai receber um pedido duplicado ou ser cobrado duas vezes ou deixar ele receber porque deu erro na gravação e ninguém ficou sabendo os tais bancos não ciclo tem outras características um rediz mongo Cassandra te dão menos garantias por isso podem ser mais rápidos para escrever eu já fiz um vídeo sobre no ciclo depois assistam mas quando faz sentido ser rápido

mas não ter garantias pensa um tipo de que se perdeu um registro não faz diferença por exemplo um Google Analytics todo site que tem configurado vai mandando para o analíticos cada clique cada visita dos usuários no site se uma dessas visitas se perder e não registrar no analítica não vai fazer diferença ou o seu Apple watch que fica monitorando batimentos cardíacos a cada x segundos ele manda para o servidor para ir montando um perfil da sua saúde se um desses batimentos se perder e não gravar não importa o importante é a média ao longo do

tempo São casos onde não tem as garantias esse de permite usar um outro banco mais rápido um mongo DB pode ser quase se configurar para esperar para dar ok na escrita para garantir que realmente gravou só que aí perdemos a característica de ter escrita mais rápida e vai ter que esperar de qualquer jeito Um Cassandra tem escrita atômica mas consistência eventual ou seja até garante que escreveu mas se consultarmos imediatamente talvez responda que ainda não tá lá porque a leitura caiu no outro node que ainda não sincronizou isso é útil quando o que queremos é

replicação do banco em múltiplos servidores não existe um tamanho que serve para tudo por isso que para decidir qual o banco usar precisa entender a diferença nesses perfis de todos em detalhes não vai ter uma resposta fácil para tudo Mas no geral para grande maioria da população que não há uma Startup unicórnio você realmente só precisa de um banco de dados relacional como post sendo auxiliado por um servidor de Cache como mancacher mas do que isso e não é vendo um vídeo que vai ajudar E mesmo quando falamos leitura existem leitura simples como puxar uma

lista de produtos para montar uma página e leituras complicadas que é gerar um relatório das vendas dos semestre organizado por região e tudo mais que cruza os dados de todos os pedidos feitos no semestre com os dados de todos os clientes e seja lá quantas outras tabelas para montar um único relatóriozão Quem entende de S Kelly é aquela com 500 Jones alterdiões subselex e você já trabalhou em algo assim já havia esse problema quando você o sistema ficar lento ou até para de responder toda vez que precisa gerar esse relatórios gigantes uma coisa uma pesquisa

simples que responde em poucos milissegundos outra coisa são relatórios que podem levar múltiplos segundos travando o banco inteiro e se você tiver um tráfico de 400 requisições por segundo de repente todo mundo tendo que esperar na fila até o relatório terminar e levar 10 segundos para terminar são 4.000 requisições que estamos deixando de responder centenas de pessoas tomando Tai malte no navegador e ficando irritados que o site não responde por isso que num sistema de verdade dividimos essas coisas em múltiplos servidores temos o banco principal que está ocupado gravando pedidos de pessoas de verdade e

não pode ser interrompido quando algum gerente pede um relatório gigante por isso que em serviços como heroico post ou awsrs tem fácil para se gerar servidores de réplica só para leitura é uma cópia que pode estar até alguns segundos atrasados do banco principal e que não deixa ninguém gravar nele mas como fica no servidor do banco principal mesmo se rodarmos coisas pesadas nele não interrompemos o tráfico do site que conecta em outros servidor na verdade é bem comum ter um banco principal só prescrita uma réplica só para servir dados para montar as páginas do site

e outra réplica exclusiva para tarefas administrativas como gerar relatórios quem fala que quer usar um novo ciclo porque bancos relacionais não escala não sabe o que estão falando em escala de empresas normais não unicórnios não precisa de novo soluções esotéricas de novo ciclo só são necessários se você for Netflix mas para o resto da população um banco de dados tradicional Racional com réplicas de leitura já resolve A grande maioria dos problemas lembra soluções simples de alto impacto que não existe reescrever tudo é isso que sempre queremos mas ainda temos um último problema de banco de

dados até que não é tão difícil ter réplica só de leitura e eu digo só de leitura porque tem replicação bidirecional de leitura e escrita é pouco prático e você ser considerado em situações especiais no geral é melhor ter um único servidor que concentra todas as escritas e envia os dados para réplicas só de leitura Mas isso significa que em algum momento se o tráfico do site aumentar uma situação de semana de Natal black friday da vida vai ter mais gente tentando gravar pedidos do que o servidor principal consegue suportar uma lógica comum numa página

de checkout de cobra ser mais ou menos assim a lógica do carrinho de compra já checou que tem disponibilidade dos produtos o seu front Change já coletou os dados de entrega os dados de pagamento e agora iniciamos a transação para gravar o pedido dentro da lógica dessa transação conectamos com o meio de pagamento seja Mercado Pago PayPal o que for esperamos responder ok Se Foi confirmado terminamos a transação E fechamos o convite na tabela do banco de dados e finalmente respondemos o HTML para o usuário com o número do pedido que acabamos de gerar durante

esse período todo o navegador do usuário ficou pendurado como puletinha rodando esperando chegar num dia normal de pouco movimento ou na sua máquina de desenvolvimento isso funciona perfeitinho mas um exemplo de coisa que parece simples só porque você não tem noção da realidade mas agora imagina você não controla coisas externas como meio de pagamento e no dia de black friday ele também pode ficar mais lento num dia a normal tem um monte de gente pendurado no seu servidores todo mundo tentando dar checkout nos pedidos o banco de dados tem limite de conexões tem limite de

transações e chega uma hora que mesmo tendo fila o tempo é tão longo que ele é obrigado a começar a desconectar as pessoas para conseguir trabalhar é quando o cartório tá tão cheio que não cabe mais gente dentro o que que você faz Manda todo mundo embora parte disso eu já expliquei no vídeo sobre o ingresso.com onde resolvemos a primeira parte do problema na parte da frente da loja que é da senha para as pessoas e manter uma fila muito mais longa do tipo volta mais tarde para ver se já chegou a sua vez e

pelo menos o navegador dos usuários não ficam ativamente PE nos servidores web consumindo recursos eles podem desconectar e uma lógica no navegador conecta de tempos em tempos para checar ou usa protocolos apropriados para isso como websockets mas e depois que as pessoas estão na loja e querem pagar o pedido e para surpresa de ninguém não é diferente a solução é fazer mais filas muita gente associa o número do pedido com o ID da gravação da linha na tabela que o banco de dados Auto incrementa e devolve quando tudo deu certo na gravação mas se já

estamos no cenário onde passamos do limite físico de gravações por segundo que o banco aguenta não podemos depender disso O correto é ter uma API Ou micro serviço cuja única função é me dar um número que é garantidamente único e não duplicado tem várias formas de fazer isso mas só entenda o conceito que desassociamos o número do pedido do ID da tabela de pedidos em seguida não gravamos mais o pedido direto no banco em vez disso pegamos os dados do pedido e com esse número novo jogamos num serviço de fila eu já falo disso mas

ao fazer isso quando o usuário preenche seus dados no formulário de checkout clica em pagar imediatamente devolvemos a página HTML de resposta dizendo Obrigado o número do seu pedido é xyz e assim que confirmarmos você receberá um e-mail e pronto liberamos essa pessoa para ir embora e ela para de consumir recursos no nosso sistema em vez de ter que ficar esperando é o equivalente de fazer a pessoa ir embora do cartório ou correios e dá espaço para outra pessoa entrar logo fazendo a fila anda mais rápido existem vários serviços de fila podemos usar o próprio

rediz que usamos para Kesha para ser o gerenciador da fila podemos usar um serviço feito exclusivamente para filas como Rabbit me kill ou Apache ou Active me kill ou vários desses mkwo que significa meça de kill ou meça de broker a WS oferece o Active ou react mku como serviço ou podemos usar o próprio dele que é o aws SQS de 5 kg serve-se todos são kills a vantagem de serviços de fila é que podemos ficar enviando milhares de mensagem para eles em funerarem que vai ser muito mais rápido e eficiente do que gravar no

nosso banco de dados que já tá no limite de processamento eu falei rediz ele funciona direitinho mas não é Tecnicamente feito para ser uma fila de verdade Protocolos de fila de verdade como implementado no revity mikill tem garantias como um banco de dados relacionado tem aced um serviço de fila de verdade precisa nos dar garantia de entrega ou seja se ele responde que entregou precisa ter entregue de verdade não pode duplicar a mensagem ou coisa assim além disso um erro que alguns cometem é criar uma tabela no banco de dados para usar como fila mas

estamos justamente querendo tirar a pressão do banco de dados usando uma fila não faz nenhum sentido botar a fila no banco uma vez na fila daí nosso programadores precisamos fazer uma segunda aplicação separada que chamamos de workers worker São programinhas curtos que ficam de pé esperando alguma coisa aparecer numa dessas duas eles ficam escutando essas filas normalmente falamos que assinam um canal dessas filas uma fila pode ter um canal de recebimento de pedidos outro canal de envio de e-mails canal de realizar pagamentos cada canal vai ter um worker que sabe o que fazer com a

mensagem que tiver naquele canal o worker que assina o canal de realizar pagamentos sabe como se conectar com meio de pagamento a vantagem é que separamos as atividades que não controlamos como confirmações de pagamento e não precisamos deixar o usuário pendurado esperando uma resposta mandamos usuário embora o quanto antes e mesmo que o meio de pagamento resolva demorar bem mais normal tudo bem Só vamos demorar um pouco mais para mandar o e-mail de confirmação para o usuário e não precisamos torturar o nosso banco de dados com várias transações abertas penduradas que começam a adotar e

malte sem parar de novo cada Framework web moderno tem sua forma de lidar com isso que chamamos de assíncronos Jobs no rubius tem Active job uma classe que era de application Job e implementa um método chamado perform na configuração geral dizemos que vai escutar de um redis um outro serviço de fila no note Express podemos usar a biblioteca Bull onde configuramos um objeto de kill que também diz de Que fila consumir e os workers que ele chama de consumers onde temos uma função chamada process para processar cada Job que vier da fila em Spring podemos

integrar com a parte gráfica fazendo uma classe consumer com o método consume em PHP o laravel Tem suporte nativo Onde fazemos uma classe que era de shield kill e implementa um método acho que deu para entender e cada um tem estratégias de como configurar esse sworkers Como faz Deploy e tudo mais Vocês precisam estudar a documentação oficial em qualquer outro Framework pesquisa no Google por assim quando nós Jobs mas claro Nem tudo são flores você poderia pensar então é boa então é só pendurar 500 workers atrás dessas filas que tudo vai ser processado rapidinho então

mas não alguns desses workas no final continuam precisando gravar coisas com o pedido na tabela do banco de dados principal eles podem demorar mais do que a aplicação web porque não tem o usuário pendurado esperando mas o pedido final precisa ser consolidado no banco e aí caímos de novo no problema de máximo de conexões e processamento dos servidor de banco se voltarmos naquela calculadora do heroco note que embaixo tem uma parte que eu não tinha mostrado o herocco suporta subir workers Mas cada worker vai consumir conexões no banco também se subir 10 dinos com um

processo cada 10 por processo e 10 conexões no pum vai precisar de 100 conexões do banco de dados além das conexões que já precisava para os dados de web por isso de novo não é mágica temos que ficar rebalanceando Quantos processos web versus quanto Quantos processos workas queremos ter para um certo orçamento que eu tô disposto a pagar pela infraestrutura sacaro organizar esse recurso é parecido com jogar RPG quantos pontos queremos de vida quantos pontos queremos de mágica quanto eu quero gastar em upgrade de arma não adianta ter a melhor arma mais pouca vida configurar

arquitetura web é que nem jogar RPG mas como começamos a colocar cash na camada web O que diminui a necessidade de darinos web sobra mais conexões para colocarmos mais workers E é assim que vão evoluindo de uma aplicação de um único processo que roda na sua máquina para uma que divide os recurso e nos dá oportunidades de balancear onde queremos usar mais do que vamos ver o que eu acabei de falar num diagrama para facilitar começamos assim uma caixinha que representa um processo da nossa aplicação web aquela que você sobe na sua máquina com o

comandos como npm onedrive ou Dragon boot Run esse processo vai configurado para conectar num banco de dados como post o seu navegador se conecta direto nessa caixinha Via Local roxo é 3.000 e na sua máquina tudo funciona mas numa infraestrutura de verdade como a WS azul e Google Cláudio re louco que eu gosto de usar de atropela simplicidade já começa aqui na frente da caixinha da sua aplicação vai ter um balanceador de carga como Wind next é nele que seu navegador vai se conectar quando digitar o domínio da sua aplicação é o endereço IP dele

que você configura no registro do seu domínio para DNS no painel de todos tem como configurar certificados SSL e tudo mais ele que vai pegar o tráfico dos usuários e Direcionar para containers web os danos digital Ocean chama de droplex em Cooper Miris chamamos de podes mas enfim é onde roda o processo da sua aplicação na realidade em produção não vai ter só uma caixinha da sua aplicação vai ter vários cada um numa porta separada do tal container e o balanceador de carga vai distribuindo uma requisição para cada uma delas Tentando Manter todos ocupados por

igual Se possível agora todas essas caixinhas continuam precisando se conectar no banco de dados mas já sabemos que existe um limite máximo dependendo do plano que pagamos para não perder controle cada caixinha vai ter um pulo de com o máximo de conexões reusáveis que ele pode manter para não desperdiçar recursos do banco de dados a técnica mais importante é estratégicamente colocar cash nos lugares ou mais pesados ou que são acessados com mais frequência e cujos dados não mudem muito ou que pelo menos não mude muito no espaço de alguns minutos que seja cinco minutos que

suas caixinhas não se conectam no banco faz muita diferença lembre-se temos muitas caixinhas ativas ao mesmo tempo então Subimos um novo serviço um bem cache um serviço De Cash também tem um limite de quantos megabytes ou gigabytes de Ram queremos usar De Cash e não precisamos nos preocupar sem encher esse espaço porque eu também Cash é inteligente de apagando o Cash mais velho para dar espaço para Cash mais novo e eu só dei exemplo de cachear algo que todo mundo vê igual como lista de produtos uma home page mas podemos fazer Cash por usuário assim

se o usuário ficar dando refresh na parte de perfil dele não precisa ficar toda hora indo no banco para pegar os mesmos dados vai o cache deles estratégias de caches São importantíssimos Vale estudar em detalhes mas a medida que nossa aplicação cresce temos funcionalidades pesadas integrações com serviços de terceiro mês de pagamento sistemas de gestão como RP várias coisas que aumentam o tempo de resposta e fazem nossos usuários esperar tempo indeterminado e nosso banco de dados também não tem processamento infinito mesmo colocando Cash ainda assim precisamos controlar esses recursos para isso podemos começar distribuindo a

leitura em servidores de réplica desse banco todo bom frame que tem como configurar para toda leitura ser feita no banco de dados e toda a escrita ser feita em outro banco de dados e esse banco de escrita é responsável por atualizar as réplicas mesmo se as réplicas ficarem um pouco atrasadas alguns segundos para coisas como relatório semestral de vendas ou algo assim não vai fazer diferença e para coisas como confirmação de número de pedido Podemos até deixar no cash do usuário enquanto os bancos de dados ainda não se sincronizaram assim ninguém vai a diferença de

tempo mas só isso não é suficiente o mundo ideal é que toda a requisição http feita por usuário seja devolvido imediatamente sem precisar esperar ninguém por isso Não chamamos serviços externos com o pagamentos ou outras apis no mesmo processamento de requisição http do usuário devolvemos imediatamente para ele um aguarde Depois mandamos um e-mail confirmando e criamos uma tarefa assíncrona que jogamos numa fila como SQS CAF com o mesmo rediz então instalamos uma nova caixinha aqui que vai ser responsável por isso e por fim criamos workers ou consumers para essas filas para fazer o processamento posteriori

realizar pagamento integrar com RP e integrar com nota fiscal eletrônica envio de e-mails e tudo mais e só aí confirmamos gravando no banco de dados principal como essas tarefas podem demorar um pouco mais também não saturamos o banco de dados principal e tudo continua funcionando de forma mais estável mas não é só ir subindo caixinhas aleatoriamente isso é bom ter em mente aquela calculadora que eu mostrei antes Existem várias calculadoras assim para coisas como a WS é só procurar mas não espere que alguém te dê uma resposta exata tempo médio de uma requisição não é

o único número que você precisa numa aplicação web páginas de conteúdo como lista de produtos detalhe de produtos perfil dos usuário são coisas facilmente cacheadas e que respondem rápido mas página de gerenciamento de carrinho que checa disponibilidade de produtos checkout com integração de pagamentos são páginas que demoram muito mais chutando numa página de conteúdo conseguimos responder em menos de 50 milissegundos mais uma página mais complicada de checkout poderia levar 500 milissegundos são diferenças assim de 10 vezes que se encontra em diversas partes de uma aplicação web se tirar a média vamos chegar num número tipo

100 milissegundos que não serve para muita coisa porque temos escondendo as páginas pesadas que precisaríamos otimizar e talvez estejamos otimizando páginas de conteúdo que já são o suficiente por isso eu sempre recomendo que se instale uma ferramenta online de monitoramento a melhor que eu conheço é o produto RPM da New relic tem boas alternativas como o Scout e outros que eu não conheço mas o New Red que dá um raio x mais detalhado ele mostra quem são os principais ofensores E se ele suportar o Framework web que você usa como raios é capaz de dizer

qual o controle Qual o modo qual que era que realmente está pesada assim não precisamos ficar adivinhando otimização nunca deve ser feita no shotômetro Ah eu acho que essa classe Ah eu acho que isso é fatorar esse Job fica melhor olhem os números 80% dos problemas de performance costumam ser causado por 20% da sua aplicação não precisa reescrever tudo em 10 funcionalidades deve ter duas que precisamos focar e conseguir economizar Metade dos recursos da infraestrutura inteira como no exemplo do Cash que eu mostrei no começo toda a otimização deve ser baseada em dados analíticos de

uso Real em produção da de uso de usuários de verdade usando sua aplicação por isso precisa de um New relic uma vez estabelecido quem é o ofensor Sabemos quanto tempo está consumindo e quando fizer a correção e subir em produção basta medir algumas horas dá para saber quanto foi efetivo ou não Por isso não basta funcionar só na sua máquina testando só com o usuário Assuma que você não sabe nada até medir em produção para o pessoal de fronte tem uma última otimização importante aprender a usar CDN o problema é o seguinte quando se monta

o HTML o servidor devolve para o navegador esse HTML vai conter várias tags de animais sscrips agora o navegador precisa voltar para o servidor e pedindo todos esses astros então uma requisição se multiplica em 2050 seja lá quão complexo é o HTML que você fez normalmente um servidor web é bem rápido para devolver essas coisas Já que não envolve conectar com o banco de dados apis nem nada disso mas mesmo assim em grande volume também pesa aquelas caixinhas da sua aplicação Estão perdendo tempo devolvendo imagens que podiam estar usando esse tempo para gravar mais um

pedido na sua loja cada Framework web de novo Tem formas de integrar com o CDN como a WS Claudio front ou azul lcdn ou festele CDN funciona assim em vez de escrever uma tag de imagem consórcio relativo ao seu domínio explicitamente escrevemos a URL do serviço de CDN tipo minha loja blá blá ponto com áudio front.com ou seja lá qual url que o serviço te der e escrevemos a tag de imagem usando um sorce absoluto só que isso seria um saco por dois motivos enquanto isso está desenvolvendo a aplicação nem tem o CDN configurado ainda

Daí você desenvolvedor front Change nem ia conseguir visualizar o que tá fazendo o segundo problema é se inscrever na mão as URL do Cloud front Mas aí o pessoal de infradecia de que prefere mudar para o azul e aí sai mudando todas as URL na mão de novo Lógico que não para isso usamos réupers funções que escrevem a URL para você em vez de escrever o URL relativo absoluta pro CDN use a linguagem de do seu Framework e chame funções por exemplo no note Express usando ejs poderia escrever a tag de imagens assim como nesse

exemplo essa função Vai checar se tá rodando na sua máquina local daí escreve a URL relativa normal e quando estiver em produção Fazemos uma configuração que indica para função Qual é a URL do CDN e ele reescreve usando a URL absoluta esse exemplo é usando Xpress CDN Mas tem várias bibliotecas que fazem a mesma coisa é importante que todo o desenvolvedor de front saiba fazer isso para depois não ter que ficar caçando URL hard code para sair mudando em massa um dia antes do primeiro depois a vantagem de fazer isso é que a partir de

agora esse efeito direito sua aplicação web devolve o HTML pro navegador o navegador encontra essa tag de imagem apontando pro servidor de CDN e vai pedir para lá o servidor de CDN Vai checar Hum eu tenho essa imagem não daí ele vai pedir só uma vez para sua aplicação web e vai cachear a imagem de resposta todo mundo que pedir a mesma imagem vai pegar do Cash do CDN e não vai mais pesar na sua aplicação de novo é outra coisa que remove uma quantidade grande de requisições feitas na sua infra e move tudo para

infra de CDN Com Outra vantagem CDs grandes costumam sincronizar seus dados em servidores de diversas regiões geográficas pelo mundo então mesmo que você tenha feito Depois da sua aplicação no servidor do Brasil se alguém do Japão acessar pelo menos todas as imagens CSS o arquivo java script podem ser puxados de servidores de CDN e do Japão o que vai proporcionar uma experiência melhor para os usuários no final todo mundo ganha isso é infraestrutura fica melhor balanceada finalizando estude estratégias De Cash usando componentes como man Caps estude Jobs a sincrus usando serviços como a WS SQS

ou Kafka Studio Como monitorar e conseguir métricas reais da sua aplicação em produção e estude como integrar CDN no seu front Change são quatro das principais técnicas de otimização que toda a aplicação web precisa e isso porque eu pulei mais vale mencionar que saber fazer queres SQL otimizados e instalar insadequados também melhora tudo uma ordem de grandeza só porque o seu frame que esconde o SQL não significa que você pode ignorar SQL um monte de problemas de performance são causados por SQL mal feito mas por hoje eu vou acabar aqui eu só queria rapidamente mostrar

alguns dos aspectos que separam uma aplicação web que funciona só na sua máquina mas que não escala de verdade em produção e como isso não tem nada a ver com sua escolha de linguagens framewords mas sim do seu não entendimento de como uma aplicação de verdade realmente funciona eu mostrei só o Pico do iceberg e eu tenho certeza que muita gente experiente vai complementar o que eu falei nos comentários Então se ficaram com dúvidas Não deixe de mandar aqui embaixo se curtir o vídeo deixa um joinha assine o canal e compartilhem um vídeo com seus

amigos a gente se vê até mais prática ele esconder esconder um proxy reverso como edinext é nele que também instalamos que pariu espera um conjunto de endereços de endereços Cash do usuário enquanto os bancos