gRPC を使用したパフォーマンスのベストプラクティス

[アーティクル]
11/06/2024

Note

これは、この記事の最新バージョンではありません。現在のリリースについては、この記事の .NET 8 バージョンを参照してください。

警告

このバージョンの ASP.NET Core はサポート対象から除外されました。詳細については、「.NET および .NET Core サポートポリシー」を参照してください。現在のリリースについては、この記事の .NET 8 バージョンを参照してください。

重要

この情報はリリース前の製品に関する事項であり、正式版がリリースされるまでに大幅に変更される可能性があります。 Microsoft はここに示されている情報について、明示か黙示かを問わず、一切保証しません。

現在のリリースについては、この記事の .NET 8 バージョンを参照してください。

作成者: James Newton-King

gRPC は、高パフォーマンスサービス向けに設計されています。このドキュメントでは、gRPC から最大限のパフォーマンスを得る方法について説明します。

gRPC チャネルを再利用する

gRPC の呼び出しを行う場合は、gRPC チャネルを再利用する必要があります。チャネルを再利用すると、既存の HTTP/2 接続を介して、呼び出しを多重化できます。

gRPC 呼び出しごとに新しいチャネルが作成された場合、完了までにかかる時間が大幅に増加する可能性があります。呼び出しのたびに新しい HTTP/2 接続が作成されるため、クライアントとサーバーの間に次のような複数のネットワークラウンドトリップが必要になります。

ソケットを開く
TCP 接続を確立する
TLS ネゴシエーションを行う
HTTP/2 接続を開始する
gRPC 呼び出しを行う

チャネルは、gRPC 呼び出しの間で安全に共有し、再利用できます。

gRPC クライアントはチャネルを使用して作成されます。 gRPC クライアントは軽量なオブジェクトであり、キャッシュしたり再利用したりする必要はありません。
異なる種類のクライアントを含め、1 つチャネルから複数の gRPC クライアントを作成できます。
チャネルおよびそのチャネルから作成されたクライアントは、複数のスレッドで安全に使用できます。
チャネルから作成されたクライアントは、複数の同時呼び出しを行えます。

gRPC クライアントファクトリには、チャネルを構成するための一元的な方法が用意されています。基になるチャネルが自動的に再利用されます。詳細については、「.NET での gRPC クライアントファクトリの統合」を参照してください。

接続の同時実行

HTTP/2 接続では、通常、1 つの接続で同時に実行できるストリームの最大数 (アクティブな HTTP 要求数) に制限があります。既定では、ほとんどのサーバーの同時に実行できるストリームの制限数は 100 に設定されます。

gRPC チャネルは 1 つの HTTP/2 接続を使用し、その接続で同時呼び出しが多重化されます。アクティブな呼び出しの数が接続ストリームの制限に達すると、追加の呼び出しがクライアントのキューに入れられます。キューに入れられた呼び出しは、アクティブな呼び出しが完了するのを待ってから送信されます。高負荷のアプリケーションや、長時間実行されるストリーミング gRPC 呼び出しでは、この制限により、呼び出しキューが原因でパフォーマンスの問題が発生する可能性があります。

.NET 5 により、SocketsHttpHandler.EnableMultipleHttp2Connections プロパティが導入されています。 true に設定すると、同時実行ストリームの制限に達したときに、チャネルによって追加の HTTP/2 接続が作成されます。 GrpcChannel が作成されると、その内部の SocketsHttpHandler が、追加の HTTP/2 接続を作成するように自動的に構成されます。アプリによって独自のハンドラーが構成される場合は、EnableMultipleHttp2Connections を true に設定することを検討してください。

var channel = GrpcChannel.ForAddress("https://localhost", new GrpcChannelOptions
{
    HttpHandler = new SocketsHttpHandler
    {
        EnableMultipleHttp2Connections = true,

        // ...configure other handler settings
    }
});

gRPC 呼び出しをする .NET Framework アプリは、WinHttpHandler を使用するように構成する必要があります。 .NET Framework アプリでは、WinHttpHandler.EnableMultipleHttp2Connections プロパティを true に設定して、追加の接続を作成できます。

.NET Core 3.1 アプリには、2 つの回避策があります。

高負荷のアプリの領域に対して、別々の gRPC チャネルを作成します。たとえば、Logger gRPC サービスに高い負荷がかかることがあります。別個のチャネルを使用して、このアプリに LoggerClient を作成します。
gRPC チャネルのプールを使用します。たとえば、gRPC チャネルの一覧を作成します。 Random は、gRPC チャネルが必要になるたびに一覧からチャネルを選択するために使用されます。 Random を使用すると、複数の接続で呼び出しがランダムに分散されます。

重要

この問題を解決するもう 1 つの方法は、サーバーの最大同時実行ストリーム制限を増やすことです。 Kestrel では、これは MaxStreamsPerConnection で構成されます。

最大同時実行ストリーム制限を増やすことはお勧めしません。 1 つの HTTP/2 接続でストリームが多すぎると、パフォーマンスの新たな問題が発生します。

ストリーム間のスレッド競合により、接続への書き込みが試行されます。
接続パケットが失われると、TCP 層ですべての呼び出しがブロックされます。

クライアントアプリの `ServerGarbageCollection`

.NET ガベージコレクターには、ワークステーションガベージコレクション (GC) とサーバーガベージコレクションの 2 つのモードがあります。それぞれは別のワークロードに合わせて調整されています。 ASP.NET Core アプリでは、既定でサーバー GC が使用されます。

一般に、同時実行数が多いアプリはサーバー GC の方がパフォーマンスが向上します。 gRPC クライアントアプリが多数の gRPC 呼び出しを同時に送受信している場合は、サーバー GC を使用するようにアプリを更新すると、パフォーマンスが向上する可能性があります。

サーバー GC を有効にするには、アプリのプロジェクトファイルで <ServerGarbageCollection> を設定します。

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

ガベージコレクションの詳細については、「ワークステーションとサーバーのガベージコレクション」を参照してください。

Note

ASP.NET Core アプリでは、既定でサーバー GC が使用されます。 <ServerGarbageCollection> の有効化は、gRPC クライアントコンソールアプリなど、サーバー以外の gRPC クライアントアプリでのみ役立ちます。

負荷分散

gRPC では、一部のロードバランサーが効率よく動作しません。 L4 (トランスポート) ロードバランサーは、TCP 接続をエンドポイント間で分散することで、接続レベルで動作します。この方法は、HTTP/1.1 を使用して行われた API 呼び出しを負荷分散する場合に適しています。 HTTP/1.1 で行われる同時呼び出しは異なる接続で送信されるため、エンドポイント間で負荷を分散することができます。

L4 ロードバランサーは接続レベルで動作するため、gRPC ではうまく機能しません。 gRPC は HTTP/2 を使用します。これにより、1 つの TCP 接続での複数の呼び出しが多重化されます。その接続でのすべての gRPC 呼び出しが、1 つのエンドポイントに送られます。

gRPC を効果的に負荷分散するには、次の 2 つのオプションがあります。

クライアント側の負荷分散
L7 (アプリケーション) のプロキシ負荷分散

Note

gRPC 呼び出しのみが、エンドポイント間で負荷分散できます。ストリーミング gRPC 呼び出しが確立されると、ストリームを介して送信されるすべてのメッセージが 1 つのエンドポイントに送られます。

クライアント側の負荷分散

クライアント側の負荷分散では、クライアントがエンドポイントを認識します。各 gRPC 呼び出しの場合は、呼び出しの送信先として、別のエンドポイントが選択されます。クライアント側の負荷分散は、待機時間が重要な場合に適しています。クライアントとサービスの間にプロキシが存在しないため、呼び出しはサービスに直接送信されます。クライアント側の負荷分散には、使用可能なエンドポイントを各クライアントが追跡し続ける必要があるという欠点があります。

ルックアサイドクライアントの負荷分散は、負荷分散の状態を中央の場所に格納する手法です。クライアントは、負荷分散の決定を行うときに使用する情報を中央の場所に定期的にクエリします。

詳細については、「gRPC クライアント側の負荷分散」を参照してください。

プロキシの負荷分散

L7 (アプリケーション) プロキシは、L4 (トランスポート) プロキシよりも高いレベルで動作します。 L7 プロキシは HTTP/2 を認識します。プロキシは、1 つの HTTP/2 接続で多重化された gRPC の呼び出しを受信し、複数のバックエンドエンドポイントに分散させます。プロキシを使うと、クライアント側で負荷分散するより簡単ですが、gRPC の呼び出しでの待ち時間が長くなります。

使用できる L7 プロキシは多数あります。次のようなオプションがあります。

Envoy - 広く普及しているオープンソースプロキシ。
Linkerd - Kubernetes のサービスメッシュ。
YARP: Yet Another Reverse Proxy - .NET で記述されたオープンソースプロキシ。

プロセス間通信

クライアントとサービス間の gRPC 呼び出しは、通常、TCP ソケットを介して送信されます。 TCP はネットワーク経由の通信に適していますが、クライアントとサービスが同じコンピューター上にある場合は、プロセス間通信 (IPC) の方が効率的です。

同じマシン上のプロセス間の gRPC 呼び出しには、UNIX ドメインソケットや名前付きパイプなどのトランスポートを使用することを検討してください。詳細については、「gRPC を使用したプロセス間通信」を参照してください。

キープアライブ ping

キープアライブ ping を使用して、非アクティブな状態の間 HTTP/2 接続を維持することができます。アプリでアクティビティが再開されるときに既存の HTTP/2 接続が準備できていると、接続の再確立による遅延が発生することなく、初期の gRPC 呼び出しをすばやく行うことができます。

キープアライブ ping は SocketsHttpHandler に構成されます。

var handler = new SocketsHttpHandler
{
    PooledConnectionIdleTimeout = Timeout.InfiniteTimeSpan,
    KeepAlivePingDelay = TimeSpan.FromSeconds(60),
    KeepAlivePingTimeout = TimeSpan.FromSeconds(30),
    EnableMultipleHttp2Connections = true
};

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions
{
    HttpHandler = handler
});

上記のコードにより、非アクティブな状態の間 60 秒ごとにキープアライブ ping をサーバーに送信するチャネルが構成されます。 ping により、サーバーと使用中のすべてのプロキシが、非アクティブが理由で接続が閉じられることがないように保証されます。

Note

キープアライブの ping は単に接続を維持するためのものです。接続に対して実行時間の長い gRPC 呼び出しがある場合、非アクティブという理由でサーバーまたは中間プロキシによって終了される可能性があります。

フロー制御

HTTP/2 フロー制御は、大量のデータによってアプリが過負荷になることを防ぐ機能です。フロー制御を使用する場合:

HTTP/2 の接続と要求それぞれに使用可能なバッファーウィンドウがあります。バッファーウィンドウとは、アプリが一度に受け取ることができるデータの量です。
フロー制御がアクティブになるのは、バッファーウィンドウがいっぱいになったときです。アクティブ化されると、送信アプリは、それ以上のデータの送信を一時停止します。
受信アプリがデータを処理すると、バッファーウィンドウ内のスペースが使用可能になります。送信アプリがデータの送信を再開します。

フロー制御がパフォーマンスに悪影響を与える可能性があるのは、大きなメッセージを受信するときです。バッファーウィンドウが受信メッセージペイロードよりも小さい場合、またはクライアントとサーバーの間に待機時間がある場合は、開始/停止バーストでデータを送信できます。

フロー制御のパフォーマンスの問題は、バッファーウィンドウのサイズを大きくすることで解決できます。 Kestrel では、これはアプリ起動時に InitialConnectionWindowSize と InitialStreamWindowSize を使用して構成します。

builder.WebHost.ConfigureKestrel(options =>
{
    var http2 = options.Limits.Http2;
    http2.InitialConnectionWindowSize = 1024 * 1024 * 2; // 2 MB
    http2.InitialStreamWindowSize = 1024 * 1024; // 1 MB
});

レコメンデーション:

gRPC サービスが 768 KB (Kestrel の既定ストリームウィンドウサイズ) を超えるメッセージをよく受け取る場合は、接続ウィンドウサイズとストリームウィンドウのサイズを増やすことを検討してください。
接続ウィンドウのサイズは、必ずストリームウィンドウサイズ以上にする必要があります。ストリームは接続の一部であり、送信側は両方によって制限されます。

フロー制御のしくみの詳細については、HTTP/2 フロー制御 (ブログ記事) を参照してください。

重要

Kestrel のウィンドウサイズを増やすと、Kestrel がアプリのためにバッファー処理するデータが増えるため、メモリ使用量が増える可能性があります。不必要に大きなウィンドウサイズを構成しないでください。

ストリーミング呼び出しを適切に完了する

ストリーミング呼び出しの適切な完了を試みます。呼び出しを適切に完了すると、不要なエラーを避けられ、サーバーは要求間で内部データ構造を再利用できます。

クライアントとサーバーがメッセージの送信を完了しており、ピアがすべてのメッセージを読み取っていると、呼び出しは適切に完了します。

クライアント要求ストリーム:

クライアントが、要求ストリームへのメッセージの書き込みを終えて、call.RequestStream.CompleteAsync() でストリームを完了します。
サーバーが、要求ストリームからすべてのメッセージを読み取ります。メッセージの読み取り方法に応じて、requestStream.MoveNext() が false を返すか、requestStream.ReadAllAsync() が終了します。

サーバー応答ストリーム:

サーバーが応答ストリームへのメッセージの書き込みを終えて、サーバーメソッドが終了します。
クライアントが、応答ストリームからすべてのメッセージを読み取ります。メッセージの読み取り方法に応じて、call.ResponseStream.MoveNext() が false を返すか、call.ResponseStream.ReadAllAsync() が終了します。

双方向ストリーミング呼び出しの適切な完了の例については、双方向ストリーミング呼び出しの実行に関する記事をご覧ください。

サーバーストリーミング呼び出しには要求ストリームはありません。つまり、クライアントは、ストリームを取り消すことでしか、それを停止する必要があることをサーバーに通知できません。取り消された呼び出しによるオーバーヘッドがアプリに影響を与える場合は、サーバーストリーミング呼び出しを双方向ストリーミング呼び出しに変更することを検討します。双方向ストリーミング呼び出しでは、クライアントが要求ストリームを完了することで、呼び出しの終了をサーバーに通知できます。

ストリーミング呼び出しを破棄する

必要なくなったストリーミング呼び出しは、常に破棄します。ストリーミング呼び出しの開始時に返される型で、IDisposable が実装されています。不要になった呼び出しを破棄すると、確実に停止されて、すべてのリソースがクリーンアップされます。

次の例では、AccumulateCount() の呼び出しでの using 宣言により、予期しないエラーが発生した場合に常に破棄されます。

var client = new Counter.CounterClient(channel);
using var call = client.AccumulateCount();

for (var i = 0; i < 3; i++)
{
    await call.RequestStream.WriteAsync(new CounterRequest { Count = 1 });
}
await call.RequestStream.CompleteAsync();

var response = await call;
Console.WriteLine($"Count: {response.Count}");
// Count: 3

できる限り、ストリーミング呼び出しを適切に完了する必要があります。呼び出しを破棄すると、予期しないエラーが発生した場合に、クライアントとサーバーの間の HTTP 要求が確実に取り消されます。ストリーミング呼び出しが誤って実行状態のままになると、クライアントのメモリとリソースがリークするだけでなく、サーバーでも実行されたままになります。多くのストリーミング呼び出しがリークすると、アプリの安定性に影響する可能性があります。

既に適切に完了したストリーミング呼び出しを破棄しても、悪影響はありません。

単項呼び出しをストリーミングに置き換える

gRPC 双方向ストリーミングを使用して、高パフォーマンスのシナリオで単項 gRPC 呼び出しを置き換えることができます。双方向ストリームが開始されると、メッセージのやり取りが、複数の単項 gRPC 呼び出しでメッセージを送信するよりも高速になります。ストリームメッセージは、既存の HTTP/2 要求にデータとして送信され、各単項呼び出しに対して新しい HTTP/2 要求を作成するオーバーヘッドがなくなります。

サービスの例:

public override async Task SayHello(IAsyncStreamReader<HelloRequest> requestStream,
    IServerStreamWriter<HelloReply> responseStream, ServerCallContext context)
{
    await foreach (var request in requestStream.ReadAllAsync())
    {
        var helloReply = new HelloReply { Message = "Hello " + request.Name };

        await responseStream.WriteAsync(helloReply);
    }
}

クライアントの例:

var client = new Greet.GreeterClient(channel);
using var call = client.SayHello();

Console.WriteLine("Type a name then press enter.");
while (true)
{
    var text = Console.ReadLine();

    // Send and receive messages over the stream
    await call.RequestStream.WriteAsync(new HelloRequest { Name = text });
    await call.ResponseStream.MoveNext();

    Console.WriteLine($"Greeting: {call.ResponseStream.Current.Message}");
}

パフォーマンス上の理由で単項呼び出しを双方向ストリーミングに置き換えることは高度な手法であり、多くの状況では適切ではありません。

ストリーミング呼び出しの使用は、次の場合に適しています。

高スループットまたは短い待機時間が必要とされている。
gRPC と HTTP/2 が、パフォーマンスのボトルネックとして特定された。
クライアントのワーカーが、gRPC サービスを使用して通常のメッセージを送受信している。

単項ではなく、ストリーミング呼び出しを使用する場合は、さらに複雑になり、制限事項が追加されることに注意してください。

ストリームは、サービスまたは接続エラーによって中断される可能性があります。エラーが発生した場合にストリームを再開するためのロジックが必要です。
RequestStream.WriteAsync は、マルチスレッドでは安全ではありません。一度に 1 つのストリームに書き込むことができるメッセージは 1 つだけです。 1 つのストリームで複数のスレッドからメッセージを送信するには、メッセージをマーシャリングするための Channel<T> のようなプロデューサーまたはコンシューマーキューが必要です。
gRPC ストリーミング方式は、1 種類のメッセージの受信と 1 種類のメッセージの送信に制限されます。たとえば、rpc StreamingCall(stream RequestMessage) returns (stream ResponseMessage) により、RequestMessage が受信され、ResponseMessage が送信されます。 Any と oneof を使用した不明なメッセージまたは条件付きメッセージに対する Protobuf のサポートにより、この制限を回避できます。

バイナリペイロード

バイナリペイロードは、bytes スカラー値型の Protobuf でサポートされています。 C# で生成されたプロパティにより、プロパティの型として ByteString が使用されます。

syntax = "proto3";

message PayloadResponse {
    bytes data = 1;
}

Protobuf は、オーバーヘッドを最小限に抑えて、大きなバイナリペイロードを効率的にシリアル化するバイナリ形式です。 JSON のようなテキストベースの形式では、base64 へのバイトのエンコードが必要で、メッセージサイズが 33% 追加されます。

大きな ByteString ペイロードを使用する場合は、以下に説明する、不要なコピーや割り当てを回避するためのいくつかのベストプラクティスがあります。

バイナリペイロードの送信

ByteString インスタンスは通常 ByteString.CopyFrom(byte[] data) を使用して作成されます。このメソッドでは、新しい ByteString と新しい byte[] が割り当てられます。データは、新しいバイト配列にコピーされます。

UnsafeByteOperations.UnsafeWrap(ReadOnlyMemory<byte> bytes) を使用して ByteString インスタンスを作成すると、追加の割り当てとコピーを回避できます。

var data = await File.ReadAllBytesAsync(path);

var payload = new PayloadResponse();
payload.Data = UnsafeByteOperations.UnsafeWrap(data);

ByteString の使用中に変更が行われないように、UnsafeByteOperations.UnsafeWrap を使用してもバイトはコピーされません。

UnsafeByteOperations.UnsafeWrap には、Google.Protobuf バージョン 3.15.0 以降が必要です。

バイナリペイロードの読み取り

ByteString.Memory および ByteString.Span プロパティを使用して、ByteString インスタンスからデータを効率的に読み取ることができます。

var byteString = UnsafeByteOperations.UnsafeWrap(new byte[] { 0, 1, 2 });
var data = byteString.Span;

for (var i = 0; i < data.Length; i++)
{
    Console.WriteLine(data[i]);
}

これらのプロパティにより、コードでは割り当てやコピーを行わずに、ByteString からデータを直接読み取ることができます。

ほとんどの .NET API には ReadOnlyMemory<byte> および byte[] のオーバーロードがあるため、ByteString.Memory は基になるデータを使用するための推奨される方法です。ただし、アプリでデータをバイト配列として取得する必要がある場合もあります。バイト配列が必要な場合は、MemoryMarshal.TryGetArray メソッドを使用して、データの新しいコピーを割り当てることなく ByteString から配列を取得できます。

var byteString = GetByteString();

ByteArrayContent content;
if (MemoryMarshal.TryGetArray(byteString.Memory, out var segment))
{
    // Success. Use the ByteString's underlying array.
    content = new ByteArrayContent(segment.Array, segment.Offset, segment.Count);
}
else
{
    // TryGetArray didn't succeed. Fall back to creating a copy of the data with ToByteArray.
    content = new ByteArrayContent(byteString.ToByteArray());
}

var httpRequest = new HttpRequestMessage();
httpRequest.Content = content;

上記のコードでは次の操作が行われます。

MemoryMarshal.TryGetArray を使用して ByteString.Memory からの配列の取得を試みます。
正常に取得された場合は、ArraySegment<byte> を使用します。セグメントには配列への参照、オフセット、およびカウントが含まれます。
それ以外の場合、ByteString.ToByteArray() による新しい配列の割り当てにフォールバックします。

gRPC サービスと大規模なバイナリペイロード

gRPC と Protobuf では、大規模なバイナリペイロードを送受信できます。バイナリペイロードをシリアル化する場合、バイナリの Protobuf のほうがテキストベースの JSON よりも効率的ですが、大規模なバイナリペイロードを操作する場合には、重要なパフォーマンス特性にも留意する必要があります。

gRPC はメッセージベースの RPC フレームワークです。そのため、次のような特性があります。

gRPC がメッセージを送信する前に、メッセージ全体がメモリに読み込まれます。
メッセージが受信されると、メッセージ全体がメモリ内に逆シリアル化されます。

バイナリペイロードは、バイト配列として割り当てられます。たとえば、10 MB のバイナリペイロードの場合は、10 MB のバイト配列が割り当てられます。メッセージのバイナリペイロードが大きい場合、大規模なオブジェクトヒープにバイト配列が割り当てられる可能性があります。大規模な割り当ては、サーバーのパフォーマンスとスケーラビリティに影響します。

大規模なバイナリペイロードを扱うアプリケーションで高パフォーマンスを維持するためのアドバイス:

大規模なバイナリペイロードを gRPC メッセージに含めることは避けてください。 85,000 バイトを超えるバイト配列は、大規模なオブジェクトと見なされます。サイズを小さくすることで、大規模なオブジェクトヒープへの割り当てを回避できます。
gRPC ストリーミングを使用して、大規模なバイナリペイロードを分割することを検討してください。バイナリデータが複数のメッセージに分割され、ストリーミングされます。ファイルをストリーミングする方法について詳しくは、grpc-dotnet リポジトリの例を参照してください。
- gRPC ストリーミングファイルのダウンロード。
- gRPC ストリーミングファイルのアップロード。
大規模なバイナリデータには gRPC を使用しないようにすることを検討してください。 ASP.NET Core では、gRPC サービスだけでなく、Web API を使用することもできます。 HTTP エンドポイントでは、要求と応答のストリーム本体に直接アクセスすることができます。
- 最小限の Web API を使用して要求本文を読み取る
- 最小限の Web API を使用してストリーム応答を返す

次の方法で共有

gRPC を使用したパフォーマンスのベストプラクティス

gRPC チャネルを再利用する

接続の同時実行

クライアントアプリの `ServerGarbageCollection`

負荷分散

クライアント側の負荷分散

プロキシの負荷分散

プロセス間通信

キープアライブ ping

フロー制御

ストリーミング呼び出しを適切に完了する

ストリーミング呼び出しを破棄する

単項呼び出しをストリーミングに置き換える

バイナリペイロード

バイナリペイロードの送信

バイナリペイロードの読み取り

gRPC サービスと大規模なバイナリペイロード

その他のリソース

次の方法で共有

gRPC を使用したパフォーマンスのベスト プラクティス

gRPC チャネルを再利用する

接続の同時実行

クライアント アプリの ServerGarbageCollection

負荷分散

クライアント側の負荷分散

プロキシの負荷分散

プロセス間通信

キープ アライブ ping

フロー制御

ストリーミング呼び出しを適切に完了する

ストリーミング呼び出しを破棄する

単項呼び出しをストリーミングに置き換える

バイナリ ペイロード

バイナリ ペイロードの送信

バイナリ ペイロードの読み取り

gRPC サービスと大規模なバイナリ ペイロード

その他のリソース

gRPC を使用したパフォーマンスのベストプラクティス

クライアントアプリの `ServerGarbageCollection`

キープアライブ ping

バイナリペイロード

バイナリペイロードの送信

バイナリペイロードの読み取り

gRPC サービスと大規模なバイナリペイロード