O servidor falador: por que seu aplicativo continua pedindo mais (e como ensinar algumas maneiras)

Todos nós já estivemos lá, olhando para um girador de carregamento que continua girando ou assistindo nossa conta de nuvem subindo mais alto do que o esperado. Freqüentemente, o culpado não é um pico enorme no tráfego do usuário, mas nosso próprio servidor de aplicativos, conversando, pedindo muitos dados, com muita frequência ou apenas de uma maneira muito ineficiente. É como um amigo bem-intencionado, mas excessivamente falador, que leva dez minutos para lhe dizer algo que poderia ter sido dito em trinta segundos. Essa síndrome do “servidor falador” é um assassino silencioso de desempenho e um dreno de orçamento. Pode fazer com que seu aplicativo pareça lento, causar deformação no banco de dados e aumentar os custos de rede. Como engenheiros de back-end, entender por que nossos servidores se tornam tão detalhados e como ensiná-los alguma etiqueta de comunicação básica é essencial para criar aplicativos rápidos, escaláveis ​​e econômicos. Vamos cavar e descobrir como fazer nossos aplicativos falarem mais educadamente. A raiz da raquete: o que torna um servidor tão falador? Um servidor fica conversando por alguns motivos comuns, geralmente relacionados à maneira como ele busca e envia dados. O problema da consulta n+1: este é um clássico. Imagine que você busque uma lista de dez postagens no blog. Para cada post, você busca seu autor. Essa é uma consulta para as postagens, além de mais dez consultas para cada autor. Total: Onze consultas de banco de dados em vez de apenas duas. É como pedir a um bibliotecário uma lista de livros e depois voltar para a recepção para o autor de cada livro um por um. Dados exagerados: seu endpoint da API pode retornar uma grande parte dos dados, mesmo que o cliente precise apenas de um pouquinho. Por exemplo, um endpoint de perfil de usuário pode enviar de volta todo o histórico de compras, catálogo de endereços e preferências, quando a interface do usuário só precisar de seu nome e avatar. Isso é muitos bytes desnecessários que viajam pela rede. Underbing e muitos pedidos pequenos: esse é o problema oposto. Em vez de um grande pedido, o cliente faz muitos pedidos pequenos. Por exemplo, o carregamento de um painel pode desencadear pedidos de API separados para pedidos recentes, melhores produtos, contagem de clientes e dados de vendas, todos um após o outro. Cada solicitação tem uma sobrecarga, e fazer muitos deles pode ser mais lento que uma solicitação bem otimizada. Design ineficiente da API: Às vezes, a própria API incentiva o comportamento de falsificação. Talvez não haja ponto de extremidade para buscar dados relacionados juntos, ou é difícil filtrar ou paginar resultados, forçando os clientes a pedir tudo e filtrar sua extremidade. Spotting The Loudmouths: Como diagnosticar um servidor falador antes de poder corrigir o problema, você precisa saber de onde vem o ruído. Ferramentas de monitoramento: ferramentas como o telescópio Laravel para aplicativos PHP ou serviços mais amplos, como nova relíquia, datadog ou até apenas logs detalhados do servidor, podem mostrar que você lenta consultas de banco de dados, tempos de resposta de API longos e identificar pontos de extremidade que são chamados com muita frequência. Logs de consulta de banco de dados: a maioria dos bancos de dados pode registrar todas as consultas executadas. A peneiração neles pode revelar rapidamente padrões de consulta N+1 ou consultas lentas e incomumente complexas. Ferramentas do desenvolvedor do navegador: se o seu servidor estiver falando muito com um front -end da web, a guia “Rede” nas ferramentas de desenvolvedor do seu navegador (F12) é inestimável. Ele mostra todas as solicitações, seu tamanho e quanto tempo demorou. Contas de provedores de nuvem: um pico repentino nos custos de saída da rede ou uso de banco de dados na AWS, Azure ou Google Cloud é uma enorme bandeira vermelha que algo está enviando ou recebendo mais dados do que deveria. Manners de ensino: Passos práticos para acalmar as coisas agora, vamos às coisas boas. Como tornamos nosso servidor mais educado e eficiente? 1. DO MONTO As consultas N+1 com carregamento ansioso, essa é uma das alterações mais impactantes que você pode fazer. Em Laravel, é lindamente simples. Em vez disso (que causa n+1 consultas): $ postagens = post :: all (); foreach ($ postagens como $ post) {echo $ post-> autor-> nome; // Cada chamada busca um novo autor} Digite o modo de saída de tela cheia de tela cheia, faça isso (carregamento ansioso, normalmente apenas duas consultas): $ posts = post :: com (‘autor’)-> get (); // busca todas as postagens e seus autores em duas consultas foreach ($ postagens como $ post) {echo $ post-> autor-> name; } Digite o modo de saída do modo de tela cheia, você pode até carregar vários relacionamentos, como post :: com ([‘author’, ‘comments’])-> get (). 2. Otimize as respostas da API: busque apenas o que você precisa ao projetar pontos de extremidade da API, esteja atento ao que o cliente realmente exige. Projeção: permita que os clientes especifiquem quais campos de que precisam. Algumas APIs conseguem isso com um parâmetro de campos: get /usuários? Campos = id, nome, email. Transformação de recursos: no Laravel, você pode usar os recursos da API para definir exatamente quais dados estão incluídos em uma resposta. // em app/http/resources/userResource.php função pública ToArray ($ request) {return [
‘id’ => $this->id,
‘name’ => $this->name,
‘email’ => $this->email,
// Don’t include everything by default
]; } // Em seu controlador, retorne a nova UserRESource ($ usuário); 3. Solicitações em lote: Combine pequenas tarefas em uma grande tarefa se um cliente precisar executar várias ações pequenas e independentes, considere fornecer um terminal de lote. Em vez de: postar /notificações /enviar (para notificação 1) postar /notificações /enviar (para notificação 2) … e assim por diante. Considere: Post /Notificações /Lotes-Seguindo com uma variedade de notificações no órgão de solicitação. Isso reduz significativamente a sobrecarga da rede. 4. Cache cedo, o cache frequentemente se certos dados forem caros para gerar ou buscar, mas não mudarem com frequência, cache -os. Cache de consulta ao banco de dados: cache os resultados de consultas complexas. Cache de resposta da API: cache toda a resposta de um terminal de API. Cache de objetos: valores ou objetos calculados em cache na memória (redis, memcached). Em Laravel, o cache é direto: $ Digite o modo de saída do modo de tela cheia, isso busca os produtos apenas uma vez por hora. 5. Considere o GraphQL (quando apropriado), enquanto uma mudança arquitetônica maior, o GraphQL foi projetado para resolver os problemas excessivos e submetidos a busca, permitindo que o cliente especifique exatamente quais dados precisam em uma única solicitação. Não é para todos os projetos, mas para aplicativos complexos com necessidades variadas do cliente, pode ser uma ferramenta poderosa. Dicas e truques medem antes de otimizar: não apenas adivinhe. Use ferramentas de monitoramento para identificar os gargalos reais antes de gastar tempo otimizando algo que não é o problema real. Comece pequeno: você não precisa revisar toda a sua API. Enfrente as maiores conversas primeiro, geralmente as consultas N+1 ou os pontos de extremidade mais pesados ​​da API. A comunicação do cliente é fundamental: se você estiver alterando as respostas da API, verifique se sua equipe de front -end ou outros consumidores da API estão cientes. Quebrar clientes existentes não é educado. Trade-offs: Às vezes, uma solução mais simples e levemente conversadora é melhor do que uma excessivamente complexa, altamente otimizada, especialmente para áreas de baixo tráfego. Encontre o equilíbrio certo para o seu projeto. Monitore continuamente: o servidor que foi bem-comportado ontem pode começar a conversar novamente amanhã. Fique de olho em suas métricas. Takeaways Um servidor falador não é apenas um aborrecimento, é um dreno no desempenho, na experiência do usuário e no seu orçamento em nuvem. Ao entender os culpados comuns, usando as ferramentas certas para diagnosticar o problema e aplicar técnicas práticas como carregamento ansioso, respostas otimizadas da API, lote e cache, você pode ensinar sua aplicação a se comunicar com mais eficiência. Um servidor bem-educado é uma alegria para trabalhar, tornando seus aplicativos mais rápido, mais estável e mais econômico. Trata -se de estar atento a cada viagem ao banco de dados e de todos os bytes enviados pelo fio.

Fonte