この記事は、CloudWeGo 2 周年記念シリーズの 3 回目です。
過去 1 年間に CloudWeGo Rust チームが行った作業を振り返ると、2 つのキーワードで要約すると、パフォーマンスの最適化とエコロジー構築です。この記事は主に 3 つのポイントに分かれています。1 番目のポイントは、今年の Volo の開発を大まかに要約してレビューすることです。2 番目のポイントは、Volo のパフォーマンスの最適化に焦点を当てることです。3 番目のポイントは、今後の作業に焦点を当てます。側面。
1. 今年のボロ
2022 年 8 月に、「 Rust 言語に基づく中国初の RPC フレームワーク - Volo は正式にオープンソースですVolo - 機能の完成とパフォーマンスの最適化、Pilota - 機能のアップグレード、Motore - 安定化、そしてMetainfo - 使いやすさです。
特に、今年の Volo の主要なノードと技術的なアップデートのいくつかを確認したいと思います。
-
オープンソースの直後に、コミュニティのクラスメートである @anwentec から最初の PR を受け取りました。この PR は主にユーザーが Windows での開発に Volo を使用することをサポートしており、フレームワークのマルチプラットフォーム サポートを大幅に補完します。
-
その直後、私たちはリリース以来最初の主要なパフォーマンスの最適化、つまりエンコードとデコードの再構築を導入しました。この最適化は元々、Thrift プロトコルをサポートするために Pilota のコミュニティのクラスメート @ii64 によって提案された PR からインスピレーションを得たものでした。 Volo の既存の機能ではユーザーによるカスタム コーデックの入力を十分にサポートできないことがわかったので、現在の Volo コーデックの再構築と最適化を行いました。
-
このプロセス中に、linkedbytes と faststr という 2 つのクレートもリリースしたことに言及する価値があります。これらは最適化を支援するだけでなく、Rust オープンソースの関連エコシステムを強化します。
-
最後に、エンコードとデコードの点で、安全でないコードによるいくつかの境界チェックもバイパスし、補助コンパイラーがより効率的な SIMD 並列演算命令を生成できるようになり、パフォーマンスが大幅に向上しました。 Volo の詳細な進捗状況を知りたい場合は、CloudWeGo 公式 Web サイトのリリース ノートを確認してください。
2. パフォーマンスの最適化
RPC フレームワークにおいて、最もパフォーマンスを消費するのはシリアル化とネットワーク通信です。パフォーマンスの最適化は主にこれら 2 つの点に焦点を当てています。以下の図は、完全な RPC 呼び出しリンクを示しています。私たちの最適化作業は、基本的に、以下で詳しく説明するエンコードとデコードの再構築の最適化と、安全でないエンコードとデコードの最適化に重点を置いています。シリアル化のエンコードとデコードの部分について、詳細なパフォーマンスの最適化に参加したい場合は、これが良い参考になります。
2.1 コーデック再構成の最適化
この領域の最適化は主にメモリのゼロコピー操作です。 RPC 呼び出しを行うときは、ユーザー リクエスト構造をバイナリ バイト ストリームにシリアル化してユーザー モード メモリに保存し、送信のために write システム コールを通じてカーネル モード メモリに書き込む必要があることがわかっています。最適化した -copy 部分は、最初のステップでユーザー モード メモリに保存されます。ほとんどの実装では、 write システム コールで書き込まれる内容は連続したメモリである必要があるため、Stringこれらのタイプのシリアル化にはコピー オーバーヘッドが発生します。Vec<u8>そこで質問ですが、メモリへの連続書き込みが必要ない場合、ここでのコピーは省略できるのでしょうか？答えは明らかです。ユーザー リクエスト構造内のメモリを再利用し、書き込み用にメモリをリンク リストの形式で結合することで、コピーのオーバーヘッドを節約できます。
メモリを再利用したい場合は、このメモリをいつ解放できるかを決定するために参照カウントを導入することは避けられません。その結果、元の2 つのタイプでStringはVec<u8>ニーズを満たせなくなり、Arc<String>と のようなArc<Vec<u8>>タイプが必要になります。幸いなことに、Vec<u8>オープン ソース コミュニティには、Bytes代替として使用できるバイト ライブラリの構造がすでに存在します。しかし、Stringこれに代わる良いものはなく、これが faststr ライブラリが生まれた理由の 1 つです。
faststr ライブラリは主にFastStr以下のような構造体を提供します。実際には、これを使用する際にユーザーが文字列型を選択する際の精神的負担を大幅に軽減できます。メモリを再利用するための上記の要件を満たすことに加えて、メモリをスタック上に直接割り当てるなど、小さな文字列に対する特定の最適化も行われます。もちろん、&strニーズを満たすことができるのであれば、なぜ faststr が必要なのかという疑問を持つ人もいるでしょう。実際には、そうではない場合もあります。この部分の詳細な説明については、faststr のドキュメントを参照してください。
Stringlinkedbytes ライブラリは主にリンク リストの概念を利用しており、上記で再利用したVec<u8>メモリを writev システム コールを通じて書き込みます。 LinkedBytes には 2 つの主要な部分があり、1 つは非合計Stringメモリを一時的に格納するフィールドでVec<u8>、bytesもう 1 つはメモリをつなぎ合わせるフィールドですlist。挿入のロジックを簡単に見てみましょう。挿入するときはBytes、まず現在一時的に保存されている連続メモリを分割して に挿入しlist、次に受信した を挿入しますBytes。
2.2 安全でないコーデックの最適化
この領域の最適化は主に、コンパイラが効率的なアセンブリ コードを生成できるように支援することを目的としています。 encode を例に挙げると、通常の状況では、memory に書き込む場合Vec<i64>、以下に示すようにコードを記述するのが簡単です。つまり、 this を直接走査してVecから、put_i64()書き込みメソッドを呼び出します。
しかし、このメソッドの実装を詳しく見てみるとput_i64()、書き込みを行うたびに、まずメモリが十分かどうかを判断し、十分でない場合はメモリを拡張してから書き込みを行うことがわかります。したがって、最初から十分なメモリを割り当てていれば、ここでの境界チェックを完全に省略できるので、少し変更して以下のようにコードを書くことができます。
コードを書いたら、次のステップはベンチを書いて実行するだけです。実行してみないとわかりません。もしかしたら、あなたも以前に考えたのと同じことを考えているかもしれません。境界チェックを削除するだけでは、パフォーマンスはそれほど向上しないはずですが、実際には、以下の図を見ると、実際には 7 ～ 8 倍のメリットがあります。
では、その理由を詳しく調べる必要がありますか?よく言われるように、徹底的に最適化したい場合は、アセンブリ コードを実行できません。両方をアセンブリ コードに変換して、もう一度見てみましょう。次の 2 つの図は、作成プロセス中のアセンブリ コードの一部をキャプチャしたものです。
これを読んで、SIMD 命令に慣れている学生は、境界チェックを削除した後のアセンブリ コードで、SIMD 命令がメモリ書き込みを高速化するために使用されていることに突然目覚めたと思います。パフォーマンス上の利点も合理的だと思われます。
3. 今後の展望
最後に、現在試みているプロジェクトの一部と、今後最適化に注力する部分についてネタバレします。
1. 新しいプロジェクト
1 つ目は Shmipc-rs プロジェクトです。CloudWeGo に詳しい学生は、Shmpc が現在オープン ソース プロジェクトであることを知っているかもしれませんが、これは Spec 言語バージョンの実装にすぎず、Shmpc-rs は Rust 言語バージョンの実装です。パフォーマンスを向上させるために、それまでに Volo にも統合される予定です。 Shmipc は共有メモリに基づくプロセス間通信であり、主に大きなパケットと高スループットのシナリオに適しています。
2 つ目は、コミュニティで広く使用されている Axum フレームワークと一貫した開発エクスペリエンスを提供する Volo-http プロジェクトで、ミドルウェア部分は独自のオープンソース Motore に基づいて実装されており、将来的にはパフォーマンスが向上します。また、Volo-gRPC プロジェクトと組み合わせて、ゲートウェイやその他の機能を提供することも期待されています。現在利用可能であり、誰もが一緒に体験して構築することができます。
2. 使いやすさの最適化
1 つ目はドキュメントの部分です。現在、Volo には多くの機能がありますが、そのほとんどは説明するためのドキュメントが不足しているため、将来的にはドキュメントを補足する作業を追加します。この問題をフォローアップしてください。どなたでもご参加いただけます。
2 つ目は、ベスト プラクティスの部分です。現時点では、ユーザーが学習して使用できる簡単なサンプル デモがいくつかあるだけですが、ユーザーが Volo フレームワークを学習して理解できる小規模および中規模のプロジェクトはありません。今後強化していきたい部分ですので、皆さんも導入をオススメするプロジェクトがあれば、ぜひイシューを開いて一緒に話し合ってください。
以上、CloudWeGo 2 周年を機に、Volo オープンソース 1 周年の振り返りと展望を述べさせていただきました。
プロジェクトアドレス
GitHub: https://github.com/cloudwego公式ウェブサイト: www.cloudwego.io
「Celebrated More Than Years 2」の海賊版リソースが npm にアップロードされたため、npmmirror は unpkg サービスを停止せざるを得なくなり、 最初の創設者の 数百人が参加して、一斉に米国に向かいました。 フロントエンド視覚化ライブラリと Baidu の有名なオープンソース プロジェクト ECharts - Fish 詐欺師をサポートするために「海へ行く」が、TeamViewer を使用して 398 万を送金しました。リモート デスクトップ ベンダーは何をすべきでしょうか? 周宏宜: Google に残された時間はあまり多くありません。すべての製品をオープンソースにすることが推奨されています。 ある有名なオープンソース企業の元従業員が、部下から異議を申し立てられた後、激怒しました。妊娠中の女性従業員を解雇しました。Google は Android 仮想マシンで ChromeOS を実行する方法を示しました。 ここで time.sleep(6) はどのような役割を果たしますか? マイクロソフト、中国のAIチームが「米国のために荷造りしている」という噂に反応 人民日報オンラインはオフィスソフトのマトリョーシカのような課金についてコメント：「セット」を積極的に解決することによってのみ、私たちは未来を手に入れることができる