Qt 6.8 以降、Qt GRPC および Qt Protobuf モジュールはテクニカルプレビューから正式にリリースされ、Qt フレームワークの完全サポート対象となりました。このブログ記事では、変更点、今後の方向性、そしてパフォーマンスのベンチマークから知っておきたい隠れた機能まで、これまで学んだことをご紹介します。
何が変更されましたか？
パブリック API の安定化を経て、両モジュールは成熟した Qt モジュールに期待されるような バージョン間互換性を提供しています。以降、私たちは継続的に改善を進めてきました。バグの修正、内部ロジックの簡素化、Qt GRPC と Qt Protobuf の両方で全体的なパフォーマンスの向上などです。また、ドキュメントと例を再見直し、より明確で役立つように完全に刷新しました。
プロジェクトでRPCやシリアライズを使用している場合、Qt 6.9ではこれらの技術の使用を簡単かつ高速にする数多くの改善が施されています。この投稿では、主な変更点の一部をご紹介します。
ドキュメントと学習
Qt GRPCを初めて使用する場合や、最新のベストプラクティスを確認したい場合は、新しく作成されたQt GRPCクライアントガイドが最適なスタートポイントです。
より高度なユースケースを探求している方向けに、Chat サンプル を完全に機能するクロスプラットフォームチャットアプリに再構築しました。実践的なヒント、役立つテクニック、深い洞察が含まれており、Qt GRPC を最大限に活用するための参考になります。
ベンチマークとパフォーマンス
gRPC™ エコシステムにおけるパフォーマンスの理解に多大な時間を費やしてきました。まだピークには達していませんが、これまでの知見と現在の状況をお伝えしたいと思います。当然ながら、参考となる grpc-c++ 実装との比較を行い、確かな基準点を提供しています。
すべてのベンチマークはQtバージョン6.9を使用して実施しました。トランスポート層には、TCPネットワークスタックのオーバーヘッドを排除し、クライアント側のパフォーマンス特性に焦点を当てるため、Unixドメインソケット（UDS）を選択しました。メッセージサイズを空のメッセージからgRPCのデフォルト最大値である4MiBまで幅広く設定し、システムの動作を測定しました。
以下のセクションでは、メッセージサイズが大きくなるにつれて、平均遅延、1 秒あたりのクエリ数 (QPS)、およびスループットがどのように変化するかを確認します。すべてのクライアントは、同じ grpc-c++ サーバー実装と通信しました。ベンチマークコードは、こちらでご覧いただけます。
平均遅延
メッセージあたりのペイロードサイズが約 64 KB までは、遅延はほぼ横ばいです。それを超えると、遅延が顕著になり始めます。対数スケールでのデータを見てみましょう。
予想通り、レイテンシは指数関数的に増加しており、対数スケールでは直線的に見えます。Qt GRPC は、小さなペイロードで特に優れたパフォーマンスを発揮し、ストリーミングシナリオでもナノ秒台の非常に低いレイテンシを達成しています。ただし、ペイロードサイズが大きくなるにつれて、堅牢性が低下します。
クエリ毎秒 (QPS)
処理されたクエリの数を確認すると、平均遅延の結果と一致しています。QtGrpcは小さなペイロードで優れたパフォーマンスを発揮し、クライアントストリーミングシナリオで最大120万QPSを達成しています。大きなペイロードではgrpc-c++実装に後れを取っており、今後の最適化の余地が示されています。
スループット
スループットは、固定サイズのメッセージで1秒間に転送できるデータ量を測定します。この指標は、システムがデータストリームを処理する速度を示します。現在、Qt GRPCはペイロードが約32 KBまで良好なパフォーマンスを発揮しますが、その後速度が低下します。一方、grpc-c++はスループットを継続的に向上させ、ペイロードが約1.5 MBでピークに達するまで最大7 GB/sに達します。
主要なポイント
まず、適切なペイロードサイズを選択することが、遅延とスループットの両方に大きな影響を与えることが明確です。特定のシナリオに最適なサイズを見つけることが重要です。超低遅延を目標とする場合は、32 KB 程度の小さなメッセージに限定してください。スループットを最大化するには、1.5 MB 程度の大きなメッセージがより良いパフォーマンスを発揮し、Qt GRPC のパフォーマンスはこれらのペイロードでさらに向上する見込みです。
ワークロードに適した RPC タイプを選択することも重要です。例えば、クライアント側のストリーミングが主な用途ですが、サーバーからの不規則な応答を処理するために双方向ストリーミングを使用している場合、これらを別々のクライアントとサーバーのストリームに分割することでスループットが向上する可能性があります。HTTP/2 のマルチプレクシングにより、gRPC は複数のストリームを効率的に管理するため、必要に応じて複数のストリームを開いて役割を分離することをためらわないでください。
ユニアリー呼び出しは、長期実行のベンチマークでは遅く見えるかもしれませんが、その強みもあります。リクエストが稀な場合、ユニアリー呼び出しは各リクエストをすぐに送信するため、リクエストごとの遅延が低くなります。一方、ストリーミング呼び出しはメッセージをバッチ処理するため、一部の遅延が発生する可能性があります。
さらに詳しく知りたい場合は、Qt World Summit 2025 での私の講演「QtGrpc & QtProtobuf で高速化」をご覧ください。
今後は？
これまで達成した遅延の改善には非常に満足しています。次の優先事項は、さらなる最適化が必要なスループットに焦点を当てることです。スループットの改善が遅延に影響を与える場合、これらのトレードオフを調整するための設定オプションを提供します。理想的には、優れた遅延と高いスループットの両方を実現するスマートなデフォルト設定を提供することを目標としています。
継続的な進歩を支援するため、パフォーマンスを体系的に評価し、継続的な改善を推進するための専用のベンチマーク環境を構築しました。
次のステップとしては、クライアントサイドのインターセプターとクライアントサイドのサービス設定の追加を予定しています。サーバーサイドのサポートも計画していますが、これにはより多くの時間と慎重な設計が必要です。
ご活用いただいている機能や、検討してほしいアイデアがございましたら、コメントでお知らせください。
