[Shenzhen] Yuanchuanghui : 17h26, la salle des fêtes vous attend.

Cet article est le troisième de la série de célébrations du deuxième anniversaire de CloudWeGo.

En revenant sur le travail effectué par l'équipe CloudWeGo Rust au cours de l'année écoulée, si l'on veut le résumer en deux mots-clés, c'est l'optimisation des performances et la construction écologique . Cet article est principalement divisé en trois points.Le premier point est de résumer et de passer en revue grossièrement le développement de Volo cette année.Le deuxième point est de se concentrer sur l'optimisation des performances dans Volo.Le troisième point est que nos futurs travaux se concentreront sur Which. aspects.

1. Volo cette année

En août 2022, nous avons publié une annonce officielle intitulée « Le premier framework RPC en Chine basé sur le langage Rust - Volo est officiellement open source Volo - achèvement des fonctions et optimisation des performances, Pilota - mise à niveau des capacités, Motore - stabilisation et Metainfo - facilité d'utilisation.

En particulier, nous aimerions vous faire passer en revue certains des nœuds clés et des mises à jour techniques de Volo cette année.

Peu de temps après l'open source, nous avons reçu le premier PR d'un camarade de classe de la communauté @anwentec. Ce PR aide principalement les utilisateurs à utiliser Volo pour le développement sous Windows, ce qui complète grandement la prise en charge multiplateforme du framework.
Immédiatement après, nous avons inauguré la première optimisation majeure des performances depuis la sortie - la reconstruction de l'encodage et du décodage. Cette optimisation a été initialement inspirée par un PR proposé par un camarade de classe de la communauté @ii64 dans Pilota pour prendre en charge le protocole Thrift. Dans certains cas, après discussion et communication, nous avons constaté que les capacités existantes de Volo ne peuvent pas bien aider les utilisateurs à saisir des codecs personnalisés, nous disposons donc de la reconstruction et de l'optimisation actuelles des codecs Volo.
Il convient de mentionner qu'au cours de ce processus, nous avons également publié deux crates, linkedbytes et faststr, qui non seulement aident à l'optimisation, mais enrichissent également l'écosystème open source Rust associé.
Enfin, en termes d'encodage et de décodage, nous avons également contourné certaines vérifications de limites via du code non sécurisé, permettant au compilateur auxiliaire de générer des instructions d'opération parallèle SIMD plus efficaces, améliorant ainsi considérablement les performances. Si vous souhaitez connaître la progression plus détaillée de Volo, vous pouvez consulter notre Release Note sur le site officiel de CloudWeGo .

2. Optimisation des performances

Dans le cadre RPC, les aspects les plus gourmands en performances sont la sérialisation et la communication réseau . Notre optimisation des performances se concentre principalement sur ces deux points. La figure ci-dessous montre un lien d'appel RPC complet. Notre travail d'optimisation est essentiellement concentré sur ces tâches gourmandes en CPU et en E/S. L'optimisation de la reconstruction d'encodage et de décodage et l'optimisation d'encodage et de décodage non sécurisé qui seront présentées en détail ci-dessous sont principalement axées sur In. la partie encodage et décodage de la sérialisation, si vous souhaitez participer à une optimisation approfondie des performances, alors ce sera une bonne référence.

2.1 Optimisation de la reconstruction des codecs

L'optimisation de cette zone réside principalement dans le fonctionnement sans copie de la mémoire. Nous savons que lors d'un appel RPC, la structure de la demande de l'utilisateur doit être sérialisée dans un flux d'octets binaires et stockée dans la mémoire en mode utilisateur, puis écrite dans la mémoire en mode noyau via l'appel système d'écriture pour l'envoi du zéro. -la partie de copie que nous avons optimisée est dans la première étape, elle est stockée dans la mémoire du mode utilisateur. Dans la plupart des implémentations, il y aura une surcharge de copie pour Stringces Vec<u8>types de sérialisation, car ce qui est écrit dans l'appel système d'écriture doit être une mémoire contiguë. La question est donc la suivante : si l’écriture continue en mémoire n’est pas requise, la copie ici peut-elle être omise ? La réponse est évidente. Nous pouvons économiser la surcharge de copie en réutilisant la mémoire dans la structure de requête de l'utilisateur, puis en enchaînant la mémoire sous la forme d'une liste chaînée pour l'écriture.

Si l'on souhaite réutiliser de la mémoire, il est inévitable d'introduire un comptage de références pour déterminer quand cette mémoire peut être libérée. Par conséquent, les deux types originaux de Stringet Vec<u8>ne répondent pas aux besoins. Nous avons besoin de types comme Arc<String>et . Arc<Vec<u8>>Heureusement, Vec<u8>dans la communauté open source, il existe déjà Bytesdes structures dans la bibliothèque bytes qui peuvent être utilisées comme alternatives. Mais Stringil n’y a pas de bon remplacement, et c’est l’une des raisons pour lesquelles la bibliothèque faststr est née.

La bibliothèque faststr fournit principalement une FastStrstructure.La représentation dans la structure est comme indiqué ci-dessous, en fait, il s'agit d'une collection de différents types de chaînes. Les utilisateurs peuvent réduire beaucoup de charge mentale sur la façon de choisir les types de chaînes lors de leur utilisation. En plus de répondre aux exigences ci-dessus en matière de réutilisation de la mémoire, il propose également certaines optimisations pour les petites chaînes, telles que l'allocation de mémoire directement sur la pile. Bien sûr, certaines personnes ici auront des questions. &strSi cela peut répondre aux besoins, pourquoi faststr est-il toujours nécessaire ? En fait, ce n'est pas le cas. Dans certains scénarios, nous ne pouvons pas exprimer son cycle de vie. Pour une explication détaillée de cette partie, vous pouvez consulter la documentation faststr.

StringLa bibliothèque linkedbytes s'appuie principalement sur l'idée de listes chaînées et Vec<u8>écrit la mémoire que nous avons réutilisée ci-dessus via l'appel système writev. Il y a deux parties principales dans LinkedBytes, l'une est un champ qui stocke temporairement Stringla mémoire sans somme Vec<u8>et bytesl'autre est un champ qui enchaîne les mémoires list. Vous pouvez brièvement examiner la logique de l'insertion. Lors de l'insertion Bytes, divisez d'abord la mémoire continue actuellement stockée temporairement et insérez-la dans list, puis insérez l'entrant Bytes.

2.2 Optimisation des codecs non sécurisés

L'optimisation dans ce domaine vise principalement à aider le compilateur à nous aider à générer du code assembleur efficace. En prenant encode comme exemple, dans des circonstances normales, lorsque nous écrivons en mémoire Vec<i64>, il sera facile d'écrire le code comme indiqué ci-dessous, c'est-à-dire de le parcourir directement Vec, puis d'appeler put_i64()la méthode pour écrire.

Mais si nous examinons de plus près put_i64()la mise en œuvre de la méthode, nous constaterons qu'à chaque fois qu'elle écrit, elle déterminera d'abord si la mémoire est suffisante. Si elle n'est pas suffisante, elle étendra la mémoire avant d'écrire. Donc, si nous avons alloué suffisamment de mémoire depuis le début, nous pouvons complètement omettre la vérification des limites ici, afin de pouvoir apporter une légère modification et écrire le code comme indiqué ci-dessous.

Après avoir écrit le code, l'étape suivante consiste à tester les performances. Écrivez simplement un banc et exécutez-le. Si vous ne l'exécutez pas, vous serez choqué. Peut-être que vous pensez la même chose que nous le pensions auparavant, en supprimant simplement le contrôle des limites, l'amélioration des performances ne devrait pas être grande, mais en fait, en regardant la figure ci-dessous, l'avantage est en fait 7 à 8 fois supérieur.

Il faut donc examiner de plus près pourquoi ? Comme le dit le proverbe, si vous souhaitez optimiser en profondeur, le code assembleur ne peut pas s'exécuter. Convertissons les deux en code assembleur et examinons-le à nouveau. Les deux images suivantes capturent une partie du code assembleur pendant le processus d'écriture.

Après avoir lu ceci, je pense que les étudiants qui connaissent les instructions SIMD se sont soudainement réveillés. Dans le code assembleur après la suppression de la vérification des limites, les instructions SIMD sont utilisées pour accélérer l'écriture en mémoire, c'est-à-dire qu'une instruction peut écrire plusieurs données, et ses instructions. les avantages en termes de performances sont également Cela semble raisonnable.

3. Perspectives d'avenir

Enfin, je vais vous donner un aperçu de certains des projets que nous essayons actuellement et des parties sur lesquelles nous nous concentrerons sur l'optimisation à l'avenir.

1. Nouveaux projets

Le premier est le projet Shmipc-rs. Les étudiants familiers avec CloudWeGo savent peut-être que Shmipc est désormais un projet open source, mais ce n'est que l'implémentation des versions du langage Spec et Go. Shmipc-rs est l'implémentation de la version du langage Rust. , qui sera également intégré d'ici là à Volo pour améliorer les performances. Shmipc est une communication inter-processus basée sur la mémoire partagée et convient principalement aux scénarios de paquets volumineux et à haut débit.

Le second est le projet Volo-http, qui offre une expérience de développement cohérente avec le framework Axum largement utilisé dans la communauté, et la partie middleware est implémentée sur la base de notre propre moteur open source, ce qui apportera des améliorations de performances à l'avenir. devrait également être combiné avec le projet Volo-gRPC pour fournir une passerelle et d'autres fonctions. Il est actuellement disponible et tout le monde est invité à expérimenter et à construire ensemble.

2. Optimisation de la facilité d'utilisation

La première est la partie documentation. Actuellement, il existe de nombreuses fonctionnalités fonctionnelles dans Volo, mais la plupart d'entre elles manquent de documentation pour les expliquer, de sorte que les utilisateurs ne peuvent pas bien les utiliser et les expérimenter. À l'avenir, nous mettrons en place le travail de supplémentation des documents. Suivez le problème et tout le monde est invité à participer.

La seconde est la partie des meilleures pratiques. Actuellement, il n'y a que quelques exemples de démonstrations simples dans Volo que les utilisateurs peuvent apprendre et utiliser, mais il n'y a pas de projets de petite et moyenne taille permettant aux utilisateurs d'apprendre et de comprendre le framework Volo. une partie qui doit être renforcée à l'avenir. Si tout le monde S'il y a des projets que vous recommandez de mettre en œuvre, vous êtes invités à ouvrir un numéro et à en discuter ensemble.

Ce qui précède est une revue et des perspectives sur le premier anniversaire de l'open source Volo à l'occasion du deuxième anniversaire de CloudWeGo. J'espère que cela sera utile à tout le monde.

adresse du projet

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

Premier anniversaire de l'open source de Volo——Optimisation des performances et construction écologique