[Shenzhen] Yuanchuanghui: 17h26, o salão de festas está esperando por você.”

Este artigo é o terceiro da série de comemorações do segundo aniversário do CloudWeGo.

Olhando para trás, para o trabalho realizado pela equipe CloudWeGo Rust no ano passado, se quisermos resumi-lo com duas palavras-chave, é otimização de desempenho e construção ecológica . Este artigo está dividido principalmente em três pontos. O primeiro ponto é resumir e revisar o desenvolvimento do Volo este ano. O segundo ponto é focar na otimização do desempenho no Volo. aspectos.

1. Volo este ano

Em agosto de 2022, publicamos um anúncio oficial intitulado " A primeira estrutura RPC na China baseada na linguagem Rust - Volo é oficialmente de código aberto Volo – conclusão de funções e otimização de desempenho, Pilota – atualização de capacidade, Motore – estabilização e Metainfo – facilidade de uso.

Em particular, gostaríamos de levá-lo para revisar alguns dos principais nós e atualizações técnicas do Volo este ano.

Logo após o código aberto, recebemos o primeiro PR do colega da comunidade @anwentec. Este PR oferece suporte principalmente aos usuários para usar o Volo para desenvolvimento no Windows, o que complementa muito o suporte multiplataforma do framework.
Imediatamente depois, inauguramos a primeira grande otimização de desempenho desde o lançamento - reconstrução de codificação e decodificação. Esta otimização foi originalmente inspirada em um PR proposto pelo colega da comunidade @ii64 no Pilota para apoiar o protocolo Thrift. descobrimos que os recursos existentes do Volo não podem oferecer suporte aos usuários para inserir codecs personalizados, portanto, temos a reconstrução e otimização do codec Volo atual.
Vale ressaltar que durante esse processo, também lançamos dois crates, linkedbytes e faststr, que não só auxiliam na otimização, mas também enriquecem o ecossistema relacionado do Rust open source.
Finalmente, em termos de codificação e decodificação, também contornamos algumas verificações de limites por meio de código inseguro, permitindo que o compilador auxiliar gere instruções de operação paralela SIMD mais eficientes, melhorando significativamente o desempenho. Se você quiser saber mais detalhadamente o progresso do Volo, você pode conferir nossa Nota de Lançamento no site oficial do CloudWeGo .

2. Otimização de desempenho

Na estrutura RPC, os aspectos que mais consomem desempenho são a serialização e a comunicação de rede . Nossa otimização de desempenho concentra-se principalmente nesses dois pontos. A figura abaixo mostra um link de chamada RPC completo. Nosso trabalho de otimização está basicamente concentrado nessas tarefas com uso intensivo de CPU e IO. A otimização de reconstrução de codificação e decodificação e a otimização de codificação e decodificação inseguras a serem apresentadas em detalhes abaixo são focadas principalmente em In. a parte de codificação e decodificação de serialização, se você deseja participar de uma otimização de desempenho aprofundada, esta será uma boa referência.

2.1 Otimização de reconstrução de codec

A otimização desta área é principalmente a operação de cópia zero da memória. Sabemos que ao fazer uma chamada RPC, a estrutura de solicitação do usuário precisa ser serializada em um fluxo de bytes binários e armazenada na memória do modo de usuário e, em seguida, gravada na memória do modo kernel por meio da chamada do sistema de gravação para envio. -copy parte que otimizamos é Na primeira etapa, ela é armazenada na memória do modo de usuário. Na maioria das implementações, haverá uma sobrecarga de cópia para Stringesses Vec<u8>tipos de serialização, porque o que está escrito na chamada do sistema write precisa ser uma memória contígua. Portanto, a questão é: se a gravação contínua na memória não for necessária, a cópia aqui pode ser omitida? A resposta é óbvia. Podemos economizar a sobrecarga de cópia reutilizando a memória na estrutura de solicitação do usuário e, em seguida, agrupando a memória na forma de uma lista vinculada para gravação.

Se você deseja reutilizar a memória, é inevitável introduzir a contagem de referência para determinar quando essa memória pode ser liberada. Como resultado, os dois tipos originais de Stringe Vec<u8>não atendem às necessidades. Precisamos de tipos como Arc<String>e . Arc<Vec<u8>>Felizmente, Vec<u8>na comunidade de código aberto, já existem Bytesestruturas na biblioteca de bytes que podem ser usadas como alternativas. Mas Stringnão existe um bom substituto, e esta é uma das razões pelas quais a biblioteca faststr nasceu.

A biblioteca faststr fornece principalmente uma FastStrestrutura. A representação na estrutura é mostrada abaixo. Na verdade, é uma coleção de vários tipos de string. Os usuários podem reduzir muita carga mental sobre como escolher os tipos de string. Além de atender aos requisitos acima para reutilização de memória, ele também possui certas otimizações para pequenas strings, como a alocação de memória diretamente na pilha. Claro, algumas pessoas aqui terão dúvidas. &strSe ele pode atender às necessidades, por que o faststr ainda é necessário? Na verdade, não é o caso. Em alguns cenários, não podemos expressar seu ciclo de vida. Para uma explicação detalhada desta parte, você pode ver a documentação do faststr.

StringA biblioteca linkedbytes baseia-se principalmente na ideia de listas vinculadas e Vec<u8>grava a memória que reutilizamos acima por meio da chamada de sistema writev. Existem duas partes principais no LinkedBytes, uma é um campo que armazena temporariamente Stringmemória sem soma Vec<u8>e bytesa outra é um campo que agrupa memórias list. Você pode examinar brevemente a lógica da inserção. Ao inserir Bytes, primeiro divida a memória contínua atualmente armazenada e insira-a e list, em seguida, insira a entrada Bytes.

2.2 Otimização de codec insegura

A otimização nesta área é principalmente para auxiliar o compilador a nos ajudar a gerar código assembly eficiente. Tomando encode como exemplo, em circunstâncias normais, quando escrevemos na memória Vec<i64>, será fácil escrever o código conforme mostrado abaixo, ou seja, percorrer this diretamente Vece depois chamar put_i64()o método para escrever.

Mas se olharmos mais de perto put_i64()a implementação do método, descobriremos que cada vez que ele escreve, ele primeiro determinará se a memória é suficiente. Se não for suficiente, ele expandirá a memória antes de escrever. Portanto, se alocamos memória suficiente desde o início, podemos omitir completamente a verificação de limite aqui, para que possamos fazer uma pequena modificação e escrever o código conforme mostrado abaixo.

Depois de escrever o código, a próxima etapa é o teste de desempenho. Basta escrever um banco e executá-lo. Se você não executá-lo, não saberá. Talvez você esteja pensando o mesmo que pensávamos antes, apenas retirando a verificação de limite, a melhoria de desempenho não deveria ser muito, mas na verdade, olhando a figura abaixo, na verdade tem de 7 a 8 vezes mais benefício.

Portanto, temos que examinar mais de perto por quê? Como diz o ditado, se você quiser otimizar profundamente, o código assembly não poderá ser executado. Vamos converter ambos em código assembly e examiná-los novamente. As duas imagens a seguir capturam parte do código assembly durante o processo de escrita.

Depois de ler isso, acredito que os alunos familiarizados com as instruções SIMD acordaram repentinamente. No código assembly, após remover a verificação de limite, as instruções SIMD são usadas para acelerar a escrita na memória. os benefícios de desempenho também são. Parece razoável.

3. Perspectivas futuras

Por fim, darei um spoiler sobre alguns dos projetos que estamos testando atualmente e as partes que nos concentraremos em otimizar no futuro.

1. Novos projetos

O primeiro é o projeto Shmipc-rs Os alunos familiarizados com CloudWeGo podem saber que Shmipc agora é um projeto de código aberto, mas é apenas a implementação das versões da linguagem Spec e Go. , que também será integrado ao Volo para melhorar o desempenho. Shmipc é uma comunicação entre processos baseada em memória compartilhada e é adequada principalmente para pacotes grandes e cenários de alto rendimento.

O segundo é o projeto Volo-http, que fornece uma experiência de desenvolvimento consistente com o framework Axum amplamente utilizado na comunidade, e a parte de middleware é implementada com base em nosso próprio Motore de código aberto, que trará algumas melhorias de desempenho no futuro. também deverá ser combinado com o projeto Volo-gRPC para fornecer Gateway e outras funções. Atualmente está disponível e todos são bem-vindos para experimentar e construir juntos.

2. Otimização da facilidade de uso

A primeira é a parte da documentação Atualmente, existem muitos recursos funcionais no Volo, mas a maioria deles carece de alguma documentação para explicar, para que os usuários não possam utilizá-los e experimentá-los bem. Acompanhe a edição e todos são bem-vindos a participar.

A segunda é a parte das melhores práticas Atualmente, existem apenas alguns exemplos de demonstração simples no Volo para os usuários aprenderem e usarem, mas não há projetos de pequeno e médio porte para os usuários aprenderem e compreenderem a estrutura do Volo. uma parte que precisa ser fortalecida no futuro. Se todos Se houver algum projeto que você recomende implementar, fique à vontade para abrir uma questão e discuti-los juntos.

O texto acima é uma revisão e uma perspectiva do primeiro aniversário do código aberto Volo por ocasião do segundo aniversário do CloudWeGo. Espero que seja útil para todos.

endereço do projeto

GitHub: https://github.com/cloudwego Site oficial: www.cloudwego.io

Primeiro aniversário de código aberto da Volo —— Otimização de desempenho e construção ecológica