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