ベンチマーク
gRPCは、多くの言語で高パフォーマンスなオープンソースRPCをサポートするように設計されています。このページでは、パフォーマンスベンチマークツール、テストで考慮されるシナリオ、およびテストインフラストラクチャについて説明します。
ベンチマーク
概要
gRPCは、高パフォーマンスと高生産性の両方を両立する分散アプリケーションの設計のために作られています。継続的なパフォーマンスベンチマークは、gRPC開発ワークフローの重要な部分です。マルチ言語のパフォーマンステストは、数時間ごとにマスターブランチに対して実行され、これらの数値は可視化のためのダッシュボードに報告されます。
パフォーマンステストの設計
各言語は、gRPCの WorkerService を実装したパフォーマンステストワーカーを実装しています。このサービスは、実際のベンチマークテストのクライアントまたはサーバーとしてワーカーを動作させるように指示します。これは BenchmarkService として表されます。そのサービスには2つのメソッドがあります。
- UnaryCall – 応答で返すバイト数を指定する単純なリクエストのユニバリーRPC。
- StreamingCall – UnaryCallに似た、リクエストと応答メッセージの繰り返し送受信を許可するストリーミングRPC。
これらのワーカーは、シナリオの説明（JSON形式）と、各ワーカープロセスのホスト:ポートを指定する環境変数を入力として受け取る ドライバー によって制御されます。
テスト対象の言語
以下の言語は、マスターブランチでクライアントとサーバーの両方として継続的なパフォーマンステストを実行しています。
- C++
- Java
- Go
- C#
- Node.js
- Python
- Ruby
パフォーマンステストのクライアント側およびサーバー側として実行するだけでなく、すべての言語はC++サーバーに対するクライアントとして、またC++クライアントに対するサーバーとしてテストされます。このテストは、もう一方の側をテストせずに、特定の言語のクライアントまたはサーバー実装の現在のパフォーマンスの上限を提供することを目的としています。
PHPやモバイル環境では、gRPCサーバー（パフォーマンステストに必要なもの）をサポートしていませんが、他の言語で記述されたプロキシWorkerServiceを使用してクライアント側のパフォーマンスをベンチマークすることができます。このコードはPHP用に実装されていますが、まだ継続的なテストモードにはなっていません。
テスト対象のシナリオ
テスト対象であり、上記のダッシュボードに表示されている重要なシナリオがいくつかあります。以下はその例です。
- Contentionless latency – StreamingCallを使用して、1つのクライアントが一度に1つのメッセージを送信する場合の、中央値とテール応答レイテンシ。
- QPS – 2つのクライアントと合計64チャネルがあり、各チャネルがStreamingCallを使用して一度に100件の未処理メッセージを送信する場合の、メッセージ/秒あたりのレート。
- Scalability（選択された言語）– サーバーコアあたりのメッセージ/秒数。
ほとんどのパフォーマンステストでは、セキュアな通信とプロトバフを使用しています。一部のC++テストでは、さらにセキュアでない通信とジェネリック（プロトバフ以外）APIを使用してピークパフォーマンスを表示します。将来的には、追加のシナリオが追加される可能性があります。
テストインフラストラクチャ
すべてのパフォーマンステストは、専用のGKEクラスタで実行されます。各ベンチマークワーカー（クライアントまたはサーバー）は、ワーカープールのいずれかのGKEノード（各GKEノードは個別のGCE VMです）にスケジュールされます。使用しているベンチマークフレームワークのソースコードは、test-infra githubリポジトリ で公開されています。
ほとんどのテストインスタンスは8コアシステムであり、これらはレイテンシとQPS測定の両方で使用されます。C++とJavaについては、さらに32コアシステムでのQPSテストもサポートしています。すべてのQPSテストでは、QPS測定がクライアントに限定されないように、サーバーごとに2台の同一のクライアントマシンを使用します。