前回はパフォーマンスアナライザーの概要及びユースケースについて解説しましたが、今回は「ビジュアルを更新します」をクリックした後に出現する「その他」について考察してみたいと思います。
「その他」の謎
下記は前回の画像ですが、パフォーマンスアナライザーを使用すると「その他」の部分で時間をかなり消費していることがあります。公式Docsからは
「その他 - これは、クエリの準備、他の視覚エフェクトの完了の待機、または他のバックグラウンド処理の実行のために視覚エフェクトに必要な時間です」
とだけ解説がありますが、実際にバックエンドではどのように動いているのでしょうか？
これを理解するためには、DAXクエリを含めていくつかのテクニカルな事柄を知っておく必要があります。
用語
- Report Canvas（レポート キャンバス）
Power BIレポートのユーザーインターフェースを提供し、ビジュアル（視覚要素）とフィルターをホストし、レポートの使用および作成に対するユーザーのインタラクションを管理し、表示のためにデータを取得します。Report CanvasはWebテクノロジーを使用しており、WebブラウザやWebブラウザのコンポーネントで実行されます。Report Canvasは、セマンティッククエリとして知られるPower BIのハイレベルな内部クエリ言語を使用してデータを取得します。 - Data Shape Engine (DSE)
Power BI、Power BI Desktop、Azure Analysis Services、またはSQL Server Analysis Services内でホストされたセマンティックモデルに対して、セマンティッククエリを生成し、それらを実行して評価します。 - Data Model Engine (AS)
セマンティックモデルを格納し、DAXクエリの評価など、レポートに対するサービスを提供します。モデルはPower BI、Power BI Desktop、Azure Analysis Services、またはSQL Server Analysis Servicesにホストされる可能性があります。セマンティックモデルのホストに応じて、モデルは表形式（Tabular）または多次元（Multidimensional）のいずれかとなります。表形式モデルにはインメモリテーブル、Direct Queryテーブル、またはそのようなテーブルの組み合わせ（複合モデル）が含まれる可能性があります。Direct QueryモードのテーブルへのDAXクエリは、Direct Queryデータソースへのクエリをトリガーします。たとえば、SQL ServerデータベースでバックアップされたDirect Queryテーブルに対するDAXクエリは、1つまたは複数のSQLクエリをトリガーします。
パフォーマンスアナライザーの時間
パフォーマンスアナライザーにおける時間（Duration）は、操作の開始タイムと終了タイムの差分として計算されます。時間は他の操作が完了するのを待っている間にかかる時間も含まれまれており、ビジュアルはすべて単一のユーザーインターフェーススレッドを共有しています。
- Report Canvasにかかる時間
Report Canvasとビジュアルは、上述の通り、殆どの操作を単一のUIスレッドで順次実行していきます。ビジュアルを更新するには、クエリの生成、Data Shape Engine (DSE) への評価の提出、クエリ結果の読み取り、新しいデータでビジュアルを表示するといった、複数の異なるReport Canvasの操作が必要です。同時に複数の操作を実行する必要がある場合、一部の操作は待機キューに入れられます。 - Power BIのバックエンドのサブシステム
DSE および Data Model Engine (AS) は、一般的に複数のスレッドを使用して操作を並列に実行します。
事例①
3つのビジュアルが含まれているレポートがあるとします。各ビジュアルが異なるユーザーアクション（クリックやスライシングなど）によって順次更新される場合、待機時間は発生しません。例えば、ユーザーアクション1でビジュアル①が更新され、それが完了したらユーザーアクション2でビジュアル②が更新され、そしてそれが完了したらユーザーアクション3でビジュアル③が更新されれていく、という流れになります。
上記のダイアグラムは、Report Canvasおよびバックエンドによって実行される操作を簡略化して示したものですが、複数のユーザーアクションが発生する場合、このようなシンプルな結果になります。ただし、実際には1人のユーザーが1つのビジュアルをクリックすると、他のビジュアルもクロスフィルターされ、現実的には次の事例のような複雑な形になります。
事例②
今度は3つのビジュアル全てを更新する単一のユーザーアクションを考えてみましょう。各ビジュアルを更新するための Report Canvas の操作は交互に行われます。なぜなら、一度に実行されるのは1つの操作だけだからです。一方、"バックエンド"の DSE および AS コンポーネントのクエリは一般的に並列で実行されます。これを可視化したものが下図になります。
一見すると何を表現しようとしているのか分からないですが、矢印のところに数字を振って見てみましょう。
まず、前提条件として、フロントエンド（Report Canvas）では処理が順番に行われ、一方でバックエンドでは並列処理が行われることを認識しておきます。ここから以下の順番で見ていきます。
- ステップ⓪
処理が始まる前の状態で、ビジュアル①の準備が開始されます。 - ステップ①
ビジュアル①の準備が完了し、そのクエリが実行されます。この間、ビジュアル②とビジュアル③は待機状態となりますが、ビジュアル②のクエリの準備がフロントエンドで始まります。 - ステップ②
ビジュアル①のクエリがバックエンドで実行されますが、この実行が終わる前にビジュアル②のクエリ実行がバックエンドで開始されます（並列処理）。 - ステップ③
ビジュアル①のクエリ実行が終わる前に、バックエンドでビジュアル②のクエリ実行が開始されますが、間もなくビジュアル①のクエリ実行が完了し、結果がフロントエンドに引き継がれます。この段階でフロントエンドではビジュアル③のクエリの準備が進行しているため、返されたビジュアル①の追加処理（結果の読取り）はキュー（待機）となります。 - ステップ④
ビジュアル③のクエリの準備が完了し、バックエンド処理に渡されます。同時に、フロントエンドで待機していたビジュアル①は結果の読取り処理に入ります。 - ステップ⑤
ビジュアル③のクエリ実行と、先行していたビジュアル②のクエリ実行が並行して終了し、その結果がフロントエンドに引き渡されます。ただし、ビジュアル①の結果の読取りおよびビジュアル表示が完了するまで待機します。 - ステップ⑥
同様に、ビジュアル③のクエリ実行が完了し、結果がフロントエンドに渡されますが、ビジュアル①のビジュアル表示が完了するまで待機します。なお、ビジュアル③がフロントエンドで結果の読取りを実行できるのは、ビジュアル②の結果読取りが終わってからです。最終的に、ビジュアル③の結果の読取りおよびビジュアル表示が完了した後、ビジュアル②のビジュアル表示が完了して操作が終了します。
操作の正確な順序は、ビジュアルの内容、操作の種類、およびユーザーのハードウェアなど、多くの要因に依存しますが、注目すべきは各ビジュアルにおける待機時間であり、これらの待機時間が冒頭で述べた「その他」に分類されます。
まとめ
ここまでの説明で、パフォーマンスアナライザーの各項目に対する理解が大きく深まったかと思います。通常、Power BIレポートが遅い場合は、非効率なDAXメジャーを見つけ出し、DAXクエリのパフォーマンス改善を行いますが、前回お話した「もっさり感」がある場合は、不要なオブジェクトが多くなっていないかを確認する必要があります。今回の解説からもわかる通り、不要なオブジェクトが多く存在すると、順番待ちによって「その他」の時間が肥大化していく可能性が高まります。
もう一つ理解が深まったこととして、各ビジュアルの「その他」の数値を合算できないという点が挙げられます。今回の例を見ると、ビジュアル①から③までの「待機時間」を合計しても、全体の合計時間にはならず、全体の時間を把握するにはビジュアル②のスタート時間とエンド時間の差を計算する必要が生じます。
実際には、パフォーマンスアナライザーからは全てのビジュアルに関するタイムスタンプを抽出し、アクションごとに詳細に確認する必要があります。これを可能にするのが「エクスポート」機能であり、エクスポートされたJSONファイルを可視化することでさらにさまざまな洞察を得ることができるでしょう。
詳細解説は省きますが、JSONをある程度可視化したpbixを残しておきます。興味ある方は確認してみてください。
>>ダウンロード
