SQLプロファイラーで見られる「RPC完了」のタイミングにネットワークI / Oが含まれていますか？
SQLプロファイラーで結果を監視するとき、RPC完了には結果をクライアントに送信する時間が含まれますか？それとも、サーバーがレコードの収集に費やした時間ですか？
私が尋ねている理由は、大量のデータを移動するプログラムに取り組んでいるためです。データベースはAzureでクラウドホスティングされており、コードは（現在）ローカルで実行されています。 SQLプロファイラーでRPC呼び出し時間を確認できます。行を選択するクエリは安価ではなく（インデックス付きの列でフィルター処理された大規模なテーブルは、ページング結果のテーブルの主キーで並べ替えられます）、それほど重要ではありません。データ（ページあたり10万件のレコード、実行ごとに最大6000万件のレコードを移動している状況）。
コードがAzure内で実行されると、それがより高速に実行されることを期待する必要があるかどうか知りたいです。 RPCの完了タイミングに、データがクライアントに送信されるのにかかる時間が含まれている場合、これにより時間が短縮されるはずです（私は大幅に期待しています）。 RPCの完了タイミングがサーバーがデータを選択するための時間である場合、Azure内で実行されているときはそれほど増加は見られません。
ネットワークI/Oisはrpc_completed期間*に含まれているため、これまでに説明したワークロードが改善されると思います。
ローカルのSQL Server 2016インスタンスでTCP/IPを有効にしてから、ORMを使用する.NETアプリケーションを介して一連のクエリを実行しました。以下は、そのテスト実行でのまったく同じクエリのsp_statement_completedおよびrpc_completed拡張イベントターゲットの比較です。
2行の各セットは、同じクエリの2つのイベントです。
後者はネットワーク時間を含まないため、rpc_completedは毎回sp_statement_completedよりも大幅に高くなっていることに注意してください（バッチ内のステートメントがサーバーで完了するまでにかかった時間です）。
笑うために、TCP/IPをオフにして、クエリが名前付きパイププロバイダーを通過するようにしました。
rpc_completedはまだ高いが、TCPオーバーヘッドが発生していないため、「往復」はすべて処理中なので、差は大幅に小さくなります。
*私のテストは拡張イベントで行われましたが、プロファイラーについても同じことが当てはまると思います
明確にするために、「ストリーミングプラン」の場合と同様に、ネットワーク時間をsp_statement_completedに含めることができます（これを指摘してくれた David Browne に感謝します）。
場合によっては、特に多くの結果を含む単純なクエリの場合、ステートメントの完了後に結果が送信用にスプールされないことがあります。代わりに、結果は計画の実行時に送信されます。これは「ストリーミングプラン」と呼ばれることもあり、ネストされた単純なループ結合または大きなテーブルからの*の選択によって得られます。