Tornando as chamadas de função do GCP Cloud mais rápidas

Recentemente, minha esposa e eu temos assistido a reprises de alguns programas de TV com Jeremy Clarkson (Top Gear, The Grand Tour, Clarkson's Farm). Apesar da palhaçada, ele é um sujeito bastante inteligente, embora provavelmente seja lembrado por achar que "velocidade e potência" são a resposta para tudo.

O Couchbase oferece velocidade e potência em abundância por meio de sua arquitetura. A maioria dos bancos de dados relacionais é monolítica em seu projeto, o que significa que eles só podem ser dimensionados verticalmente, não horizontalmente. Ao contrário da maioria dos bancos de dados NoSQL, cada serviço que compõe a plataforma de dados do Couchbase pode ser colocado em nós diferentes, o que significa que cada serviço pode ser dimensionado horizontal e verticalmente também. Isso permite que você coloque a energia exatamente onde ela é necessária e obtenha mais velocidade.

Apesar do valor de entretenimento de Clarkson, velocidade e potência nem sempre são a resposta, especialmente se o problema estiver no nível do projeto. A potência por meio do hardware pode ajudar a ocultar o problema, mas ela não vai desaparecer e é um desperdício. A velocidade, no entanto, costuma ser essencial nos dias de hoje, em que a lentidão é chamada de "o novo down".

Em um compromisso recente, descobrimos que alguns desenvolvedores usavam um padrão que poderia ser aprimorado em suas funções do Google usando uma dica simples. Nesta postagem do blog, compartilharemos como ajustamos o o motor (código de função) e catapultou o desempenho para a última reta, para a linha de chegada e para a próxima volta.

Continuando com o tema TV, vamos supor que você queira assistir à sua série de TV favorita em um serviço de streaming. O processo seria mais ou menos assim:

• • • Ligar a TV/Dispositivo
    • Abrir aplicativo
    • Faça login no serviço
    • Escolha o programa
    • Programa de Vigilância
    • Escolha o programa
    • Programa de Vigilância
    • Etc. etc. etc.

Quão irritante seria se o provedor de serviços o obrigasse a fazer login toda vez que quisesse assistir a outro programa? Provavelmente o suficiente para mudar para outro serviço, certo?!?

Digamos que essa seja uma chamada ao seu banco de dados a partir de uma função na nuvem.

Ligar a TV e abrir o aplicativo seria escrever e implementar suas funções. Como só faríamos essas etapas uma vez, vamos deixá-las de lado e continuar com o restante da lista.

Na imagem da esquerda, você pode ver a necessidade repetida de fazer login, enquanto na da direita o processo de login ocorre apenas uma vez e os dados de login são reutilizados durante toda a sessão. Como seria de se esperar, leva menos tempo para processar uma solicitação de informações se os detalhes de login já tiverem sido verificados e não precisarem ser enviados todas as vezes.

É aqui que o fato de não testar em escala realmente se torna um problema. Para fins de argumentação, digamos que a autenticação demorou 1 ms (sua milhagem varia de acordo com o tipo de autenticação, a distância entre o cliente e o banco de dados e uma série de outros fatores). Agora, 1 ms pode não parecer muito e, se analisarmos apenas uma ocorrência de uma execução, podemos dizer que não foi um problema. E se, em vez de apenas uma solicitação, houvesse milhares de solicitações acontecendo usando essa função? De repente, milhares de milissegundos por segundo estão sendo desperdiçados. Quando você estiver sendo cobrado pelo tempo que essas funções levam, isso lhe custará caro.

Principais dicas para um tempo de volta quente

Siga estas dicas úteis para obter uma conexão entre o Google Cloud Functions e o Capella que reduzirá o tempo de ida e volta e acelerará o ritmo:

1. 1. Globalização: Ao configurar sua função de nuvem, opte por uma conexão de banco de dados com escopo global. Isso dá à sua função um início perfeito para acessar o cluster do Capella de qualquer lugar da grade.
      
   2. Passe menos tempo nos boxes: Resista ao impulso de criar um novo Couchbase Aglomerado toda vez que sua função é chamada. Isso é como fazer um pit stop a cada volta - um pouco excessivo, não acha? Em vez disso, crie o objeto Aglomerado uma vez e, em seguida, armazená-lo para que sua função o reutilize.
   3. Ajuste o tempo ocioso: Conjunto maxIdleTimeMS para 60000 (ou seja, um minuto para nós, meros mortais com apenas segundos em um cronômetro). Isso fecha automaticamente as conexões depois que elas ficam ociosas por um minuto, evitando timeouts e mantendo suas funções sem servidor dinâmicas.
   4. A simultaneidade é fundamental: Ao criar sua função do Google Cloud: 
      • Adote a 2ª geração: É como fazer o upgrade de um Ford Modelo T para um carro de F1 - ele lida com várias solicitações simultâneas e reduz a carga da conexão, permitindo que sua função compartilhe um único Aglomerado objeto.
      • Aumente a simultaneidade: Aumente a configuração de simultaneidade para minimizar as temidas partidas a frio e dar um impulso turbo à sua latência. Pense na partida a frio como uma largada em pé em uma corrida, em comparação com uma largada em movimento, em que o participante da corrida está em alta velocidade. Em uma largada a frio/em pé, o participante precisa gastar energia para ganhar velocidade e depois concluir a atividade.
        

Exemplo: Função de nuvem Python conectando-se à Capella

Aqui está! Um exemplo em Python para otimizar seu Google Cloud Functions com o Couchbase Capella.

Vá em frente, experimente, será que é tão difícil assim?