gRPC vs rest: Por que os milissegundos são importantes

gRPC vs rest um novo sistema que os desenvolvedores estão sempre procurando a maneira melhor e mais eficiente de fazer as coisas acontecerem. Mas tornar as coisas mais eficientes às vezes é apenas uma questão de milissegundos.

No site Yonego, recentemente começaram a fazer esse desenvolvimento: mudar os serviços da web de REST para gRPC.

Serviços web

Um serviço da web é um serviço que pode ser chamado por um aplicativo. Esses serviços da web são programas separados que são independentes de outros aplicativos e podem ser executados em máquinas diferentes.

Como um exemplo da vida real, você pode comparar um serviço da Web a uma máquina de café. Esta máquina só tem uma função: fazer café. O usuário pode selecionar um café e, sem se preocupar em como é feito, uma xícara de café é feita. Um serviço da web basicamente faz o mesmo. Podemos ter um serviço web que envia e-mails. Como cliente, pode apenas dizer: “Quero enviar um email com este conteúdo…”. O serviço da web então trata de como o e-mail é realmente enviado, para que o cliente não precise mais se preocupar com isso.

<< Para programadores >>
Um serviço da Web expõe uma API (Interface de Programação de Aplicativo) para se comunicar em uma rede, geralmente por meio de HTTP (Protocolo de Transferência de Hipertexto). HTTP é um protocolo de aplicativo frequentemente usado para comunicação entre um cliente da web e um servidor da web. Um serviço da web expõe uma porta que dá a outros programas acesso à sua funcionalidade.

Outras formas de APIs podem ser muito maiores do que isso. Dependendo da API, eles podem se comunicar da maneira que desejarem. Interno, externo, em rede, em Bluetooth, não importa, desde que seja acessível de alguma forma.

API de serviço

Conforme mencionado anteriormente, esses serviços da web podem ser executados em máquinas diferentes. Isso significa que deve haver algum tipo de comunicação entre os aplicativos e o serviço da web, também conhecido como ‘API de serviço’.

Uma API de serviço é uma técnica que lida com a comunicação entre duas máquinas, como REST (REpresentational State Transfer) e gRPC (Google Remote Procedure Call). Claro, existem dezenas de APIs de serviço, cada uma com suas próprias vantagens. Mas como a Yonego começou recentemente a migrar seus serviços da web de REST para gRPC, fiquei curioso. Quão mais rápido é o gRPC do que o REST?

<< Para programadores >>
REST é uma técnica popular baseada em recursos que usa os métodos GET, POST e PUT DELETE. Recursos são entidades de dados nas quais você executa ações, como os métodos GET, POST, PUT e DELETE. A comunicação do REST geralmente inclui o envio de um JSON e pode ser executado em HTTP / 1.1 ou HTTP / 2.

gRPC é uma estrutura RPC de código aberto criada e usada pelo Google. É construído em HTTP / 2.0, o que torna possível a comunicação bidirecional. O gRPC se comunica usando dados binários usando buffers de protocolo por padrão para serializar dados estruturados. Os servidores gRPC permitem chamadas unárias entre idiomas ou chamadas de fluxo.

Avaliação comparativa
Para testar esses métodos, é criado um aplicativo de referência que executa dois testes de referência:

Múltiplos Clientes

Este teste simula vários usuários que tentam utilizar o serviço web ao mesmo tempo (concorrentes), ou mais técnico: simula vários clientes que fazem uma chamada para o servidor ao mesmo tempo. Um cliente é um usuário que está usando um serviço. Pode ser um site solicitando recursos de um serviço da web, um aplicativo móvel que inicializa uma IU (interface do usuário) e requer a exibição de dados, ou mesmo um servidor da web usando outro serviço da web. Assim como ligar para alguém no telefone, o cliente também pode ligar para um serviço, solicitando que faça uma determinada coisa.

O vencedor deste teste pode ser a melhor escolha ao fazer um serviço da web que espera várias chamadas de cliente ao mesmo tempo.

Chamadas Paralelas

Este teste simula um cliente que faz uso de um serviço da web solicitando várias tarefas ao mesmo tempo, ou mais técnicas: um cliente fazendo n chamadas para o serviço com n threads.

Esses resultados de teste são interessantes quando um serviço da web é criado e espera uma chamada regular do cliente, pedindo ao servidor para fazer várias coisas ao mesmo tempo.

<< Para o programador >>
gRPC e REST executam esses testes 50 vezes em seu próprio contêiner Docker usando uma distribuição Alpine. Isso é feito para minimizar dependências externas. Docker é uma máquina virtual que pode executar contêineres. Esses contêineres são ambientes isolados que executam apenas coisas necessárias para seu contêiner e instalam apenas o software necessário para implementar seu programa. Alpine é uma distribuição Linux leve e focada na segurança.

O resultado de ambos os testes é a duração total para a conclusão do teste. Isso significa que apenas o teste é rastreado. A duração da criação do servidor e clientes não está incluída na duração total.

Chamadas de teste

Como há muitos serviços da web diferentes fazendo coisas diferentes, cada método de teste faz chamadas diferentes para o serviço da web. Embora essas chamadas ainda sejam bastante simples, elas diferem em tamanho, o que pode resultar em resultados de teste diferentes.

Normal load

Quando um cliente envia a palavra “teste” para o serviço web, o serviço web retorna a frase “Olá teste”. Observe que, durante essa chamada, o servidor adiciona a palavra “Olá” à resposta. Adicionar “Hello” à resposta leva algum tempo, o que às vezes resulta em uma duração de chamada mais longa em comparação com o teste de carga pesada porque é necessário fazer algum trabalho antes de enviar uma resposta de volta.

Carga pesada

Quando um cliente envia uma frase pequena, uma frase grande, um número pequeno e um número grande para o serviço da web, e o serviço da web retorna esses valores. Durante esta chamada, o servidor retorna apenas os valores. O servidor não precisa fazer nenhum trabalho antes de enviar uma resposta de volta.

Resultado dos testes

Os testes resultaram em gráficos diferentes. O primeiro gráfico mostra os resultados de 50 testes (iterações). As linhas representam a duração (em milissegundos) da chamada. A grande linha azul mostra os resultados do gRPC e a grande linha vermelha mostra os resultados do REST. A pequena linha azul mostra os resultados médios do gRPC e a pequena linha verde mostra os resultados médios do REST.

O segundo gráfico mostra a duração média da chamada de todas as 50 iterações.

Observe que esses gráficos têm muitos picos. Isso ocorre porque estamos falando de milissegundos. Um milissegundo é uma unidade tão pequena que é muito fácil levar um milissegundo a mais do que outro teste.

Múltiplos clientes
Normal load

Como você pode ver, o REST é mais rápido neste teste. O gRPC tem mais sobrecarga, o que afeta a duração de uma chamada. Sobrecarga são todos os processos ou recursos extras necessários para realizar uma tarefa específica (sobrecarga, 2017 https://en.wikipedia.org/wiki/Overhead_(computing) ). Por exemplo, gRPC tem um elemento de segurança que leva um pouco de tempo. Como a carga útil (os dados transmitidos) é muito pequena, outras dependências como essa podem ter efeito na duração geral da chamada.

Um outro motivo pode ser que esses testes sejam realizados no mesmo computador, na mesma rede, na mesma porta. Isso é semelhante a pessoas que tentam descer do trem ao mesmo tempo pela mesma porta. As pessoas têm que sair uma por uma.

Internamente, o REST pode lidar com isso melhor do que o gRPC. Como isso é tratado internamente pode ser uma pesquisa por si só, portanto, neste teste, é apenas uma especulação. Em uma situação mais realista, esses clientes estão todos em redes diferentes com suas próprias portas e podem não ter esse problema.

Este teste mostra que o gRPC é mais rápido. Isso ocorre porque o gRPC geralmente usa buffer de protocolo. Este é um mecanismo para serializar dados estruturados. Serialização é o processo de traduzir estruturas de dados em um formato que pode ser armazenado, transmitido ou reconstruído posteriormente (Serialização, 2017, https://en.wikipedia.org/wiki/Serialization ). REST frequentemente envia dados usando XML ou JSON. Esses são formatos de serialização legíveis.

De acordo com o site oficial de buffers de protocolo, a serialização do buffer de protocolo é mais simples, rápida e menor do que XML (por que não usar XML ?, 2017 https://developers.google.com/protocol-buffers/docs/overview ). Isso significa que a carga útil do gRPC é menor e mais rápida que a carga útil do REST.

Com essa carga, a sobrecarga não se soma aos ganhos de velocidade extra do gRPC com o uso do buffer de protocolo.

Neste teste, podemos ver uma grande diferença entre REST e gRPC. O gRPC não tem apenas a vantagem de uma carga útil menor de dados serializados, mas também a vantagem de ter uma conexão de cliente de longa duração.

Notável é que neste teste, após cada iteração, o gRPC leva em média menos tempo para uma chamada do servidor do que no outro teste, onde, em média, uma chamada leva mais tempo após cada iteração.

O poder de um milissegundo

Os testes mostram que o gRPC costuma ser apenas alguns milissegundos mais rápido que o REST. Alguém pode pensar: “Por que isso importa? Um milissegundo é uma unidade tão pequena que nem vou notar … ”

Na verdade, um milissegundo é uma unidade muito pequena. Um usuário não notará diretamente quando sua chamada durar 1 ms a mais. Mas esse 1ms pode ser um problema para uma empresa.

Um servidor não pode processar todas as solicitações ao mesmo tempo, porque tem recursos limitados. Um servidor pode, por exemplo, processar apenas 10 solicitações ao mesmo tempo. Isso é comparável a uma empresa que pode atender apenas 10 chamadas telefônicas ao mesmo tempo, porque tem número limitado de telefones ou funcionários. Se um servidor obtiver 1000 solicitações e só puder lidar com 10 ao mesmo tempo, a última solicitação terá que esperar um pouco antes de ser tratada. Essa última solicitação pode ser você, esperando a página da web finalmente carregar.

Para trazer as coisas mais em perspectiva, digamos que eu fiz um teste de benchmark que fez 10.000 chamadas para um servidor que só pode lidar com 10 solicitações ao mesmo tempo. Presumimos que cada chamada gRPC leva 1 ms, enquanto uma chamada REST leva 2 ms. gRPC terminará em 1 segundo e REST em 2 segundos, o que é uma diferença de 1 segundo. E se meu serviço da web fizesse uma chamada para outro serviço da web com os mesmos recursos limitados antes de responder? Isso poderia adicionar mais um segundo. Isso realmente começa a aumentar quando dados maiores são enviados para serviços da web, tornando a diferença na duração ainda maior.

Uma página da web pode usar vários serviços da web diferentes que são chamados o tempo todo. Todos esses webservice podem ter diferentes recursos disponíveis. Quando uma página da web recebe mais visitantes, não é mais uma questão de milissegundos. O tempo de carregamento de uma página da web, por exemplo, pode aumentar, fazendo com que a experiência do usuário diminua. Algumas empresas corrigem esse problema comprando outro servidor. Mas isso também pode ser corrigido examinando como os dados são enviados de um serviço da web para outro.

REST vs gRPC

<< Para programadores >>
Como mostram os resultados, gRPC é mais rápido que REST na maioria dos testes. O único teste que o REST venceu foram os testes em que a carga útil era pequena e vários clientes fizeram uma chamada de servidor ao mesmo tempo.

De acordo com esses testes, ao criar um serviço da web que espera várias chamadas de cliente ao mesmo tempo e usa uma pequena carga como entrada e saída, REST pode ser a melhor escolha.

Em todas as outras ocasiões, o gRPC foi mais rápido. Podemos concluir que gRPC é nosso vencedor geral, mas além da velocidade, gRPC e REST têm suas próprias vantagens:

gRPC

gRPC pode usar buffer de protocolo para serialização de dados. Isso torna as cargas úteis mais rápidas, menores e mais simples.

Assim como o REST, o gRPC pode ser usado em linguagens cruzadas, o que significa que se você escreveu um serviço da web em Golang, um aplicativo escrito em Java ainda pode usar esse serviço da web, o que torna os serviços da web gRPC muito escalonáveis.

O gRPC usa HTTP / 2 para oferecer suporte a APIs escalonáveis ​​e de alto desempenho e usa dados binários em vez de apenas texto, o que torna a comunicação mais compacta e eficiente. O gRPC usa melhor o HTTP / 2 do que o REST. O gRPC, por exemplo, torna possível desligar a compactação de mensagens. Isso pode ser útil se você quiser enviar uma imagem que já está compactada. Comprimir novamente só leva mais tempo.

Também é seguro para o tipo. Isso basicamente significa que você não pode dar uma maçã enquanto se espera uma banana. Quando o servidor espera um número inteiro, o gRPC não permite que você envie uma string porque são dois tipos diferentes.

DESCANSAR

Como dito anteriormente, REST pode ser usado em várias linguagens, o que torna esses serviços da web flexíveis e escalonáveis.

REST também é amplamente utilizado. Muitas pessoas têm experiência com ele e muitos outros serviços da Web (e clientes) usam REST. Ter um serviço da web REST torna mais fácil para outras pessoas interagirem com o seu serviço da web.

A comunicação geralmente acontece usando um JSON, que pode ser lido por humanos. Isso torna mais fácil para os desenvolvedores determinar se a entrada do cliente é enviada corretamente ao servidor e de volta.

Mas uma das principais vantagens do REST é que ele não precisa configurar um cliente. Você acabou de fazer uma chamada para um endereço de servidor (por exemplo: www.test.nl/thisworks ). Isso funciona até mesmo se você apenas copiar um endereço de servidor REST (de um método GET) em seu navegador da web. Outras técnicas, como gRPC, geralmente exigem que você configure um cliente.

Conclusão

Com mais de um milhão de sites e ainda mais programas, muitas técnicas são usadas que quase ninguém conhece. Este artigo cobre apenas dois métodos de comunicação específicos que podem ser usados ​​em algumas ocasiões específicas, mas ainda são problemas que são tratados diariamente por desenvolvedores de back-end.

Nesses testes, o gRPC provou ser mais rápido que o REST. Na Yonego, optamos por migrar nossos serviços da Web REST para os serviços da Web gRPC devido a todas as vantagens que o gRPC tem a oferecer.

Mas, além da técnica usada, o mais notável em tudo isso é a velocidade com que isso está acontecendo. Durante esses testes, histórias inteiras foram enviadas em menos de 25 milissegundos da máquina cliente para o servidor e vice-versa. Milhares de linhas de código foram lidas e processadas apenas para o envio dos dados do servidor ao cliente, e tudo isso em tão pouco tempo.

Enviar histórias em menos de 25 milissegundos é rápido . Mas os programadores ainda estão tentando diminuir essa duração, porque sabem que em uma escala maior os milissegundos são importantes.

Esperançosamente, depois de ler este artigo, você sabe um pouco mais sobre o que os programadores consumidores de café fazem em seu trabalho diário para garantir que sua experiência de usuário seja a melhor possível.

Como estagiário na Yonego, estou migrando os webservices REST da Yonego para os webservices gRPC, começando com um simples ‘serviço de localização’. Este serviço retorna um código de país (ISO) de um endereço IP. Este código de país pode então ser usado para, por exemplo, traduzir uma página da web de acordo com sua localização atual.

Ao ler em muitos sites que uma das vantagens do gRPC é que ele é muito rápido, fiquei curioso e comecei a fazer minha própria pesquisa e observando um aplicativo que testa a velocidade do gRPC e do REST.

Recomendado para você

Author: Redação BR Acontece

Criador de conteúdo, amante da internet, TV, plataformas blogger e WordPress. Vivo conectado em um mundo chamado notícias online, sempre atualizando o site BR Acontece.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *